自從升級到 2.5.7 版後，我注意到偶爾會出現沒有「句點」卻重複執行的轉檔。昨晚，《黑名單》和一部 Hallmark 電影就跑了不只一次。我已附上日誌供檢視。
謝謝。
mcebuddy.zip (333.0 KB)
已將此移至新主題，感謝您提供的日誌。我們已找出部分轉換檔案陷入轉換迴圈的潛在原因，這是系統在高負載時發生競爭條件所導致。
此問題已在今日的 2.5.7 BETA 版本中修復，請試用並告知是否仍遇到問題。
如果新版本出现这个问题，我会通知你。谢谢。
@Goose
我昨晚又遇到了一次转换循环。这是日志。
谢谢，
dcmcebuddy.zip（163.3 KB）
好的，我们认为发现了一个潜在的竞态条件：监控位置在新文件被引擎记录为已转换文件之前就将其捕获。我们已经修复了这个问题。请尝试今天的 2.5.7 BETA 版本，现在应该可以解决了。
谢谢你，我今天会安装新版本。
@Goose
請查看昨晚雙重轉換的附加日誌。
謝謝，
djc
mcebuddy.zip (69.1 KB)
嗯，好的，我们大概知道发生了什么，这与您的网络文件系统报告了错误状态，导致 MCEBuddy 误判有关。
情况是这样的：您的目标文件夹是一个网络文件夹。原始文件大约 5 GB，移动到目标网络文件夹（同时也是被 Monitor 位置监控的源文件夹）需要很长时间。因此，当转换后的文件正在复制时，如果恰好此时 Monitor 任务扫描该文件夹，新的转换文件就会出现。理想情况下，正常系统会报告该文件正在写入/被锁定，于是 MCEBuddy 会跳过它。但出于某种原因，您的网络文件系统报告该文件已可读取，误导 MCEBuddy 认为它可用，于是将其加入队列。
我们已在今天的 2.5.7 BETA 版本中加入了针对此类可能报告错误文件锁定状态的文件系统的修复，应该可以解决。
作为参考，另一种解决方法是：在 Monitor 任务的高级设置中提高文件的“最小年龄”（默认 1 分钟——在您的情况中，复制过程耗时超过 1 分钟），比如设为 30 分钟。这样，即使文件系统错误地报告文件已就绪（实际仍在写入锁定），MCEBuddy 也会等待 30 分钟再将其加入队列；届时转换已完成且数据库已更新，30 分钟后再检查时，它会识别为已转换并跳过。
我会尝试新版本，并在明天增加最小老化时间。不过我有一个问题：既然这个问题是在修复文件名以句点结尾的问题之后才出现的，为什么现在会发生这种情况？
在修复之前，我只有在文件名以句点结尾时才会遇到这个问题。
我非常感谢你的所有帮助。
1個讚
這是兩個完全不同且無關的問題。第一個是在處理句號時的錯誤（Windows 會忽略但 MCEBuddy 不會），導致檔名不符。
第二個是一種競爭條件，只有在特定情況下才會發生（監控任務必須在檔案被移動的同時執行掃描），可能是由於你的網路檔案系統回報（或沒有回報）鎖定檔案的方式有所改變。
有了這次更新，你應該不需要提高最小檔案年齡。先試試看，確認是否如預期運作。
到目前为止，没有任何问题需要报告。