转换任务忽略最低年龄

General Support / Questions
1

我花了一些时间确认 MCE Buddy 在我的环境中运行正常（网络共享、大量录制、MCE Buddy 跑在虚拟机里等等），然后觉得可以放心开启。唯一没测试的是“处理前最小文件年龄”，我设为 3 小时就去睡了……（接下来约一小时没有录制任务，我不想干等）。结果今天一看……所有录制都只剩 1 分钟长。我过了好一会儿才意识到是 MCE Buddy 的问题；进一步测试发现，它确实在录制开始 1 分钟后就开始处理文件（可能正好赶上轮询间隔）。

各台机器时钟已同步。

有头绪吗？

MCE Buddy 版本 2.5.7（老版本一直正常，我不太想为新版付费；而且我刚换了录制源）。

2

It sounds like you’re experiencing an issue where MCEBuddy is processing files almost immediately, even though you’ve set a minimum age of 3 hours. This is definitely not the intended behavior.

Since you’re using an older version (2.5.7), it’s possible this is a known bug that has been fixed in later versions. While I understand your hesitation to upgrade, it’s often the quickest solution for issues like this, especially if you’re not seeing many other reports of this specific problem with newer versions.

Here are a few things to consider and potentially troubleshoot:

  • Poll Interval: You mentioned “maybe by chance at the poll interval.” The poll interval determines how frequently MCEBuddy checks for new recordings. If the poll interval is very short (e.g., 1 minute), it might be picking up the file quickly. However, the minimum age setting should still override this and prevent processing until the file meets the age criteria.
  • File System Timestamps: Even though you mentioned clocks are synced, sometimes network shares or virtual machine environments can have subtle timestamp issues. Double-check that the “Date Modified” timestamp of the recording file is accurate and consistently reflects when the recording actually finished. MCEBuddy relies on these timestamps.
  • MCEBuddy Logs: The MCEBuddy logs are your best friend here. They will contain detailed information about when MCEBuddy detected the file, when it decided to start processing it, and any messages related to the minimum age setting. Look for entries around the time your recordings were being processed prematurely. The logs might reveal if MCEBuddy is misinterpreting the file’s age or if there’s an error in its calculation. You can usually find the logs in the MCEBuddy installation directory.
  • Configuration Review: Double-check your MCEBuddy conversion task settings to ensure the minimum age is indeed set to 3 hours and that there aren’t any other conflicting settings that might be overriding it.
  • Known Issues for 2.5.7: It might be worth searching the forum (or even general web searches) for “MCEBuddy 2.5.7 minimum age issue” to see if others have reported similar problems with that specific version.

If you can provide some snippets from your MCEBuddy logs around the time a premature conversion happened, it would be very helpful in diagnosing the problem.

Let’s see if we can find any discussions about this particular issue.

Hello Allen, sorry to hear you’re having trouble with your recordings.

It sounds like MCEBuddy is processing your files before they’re fully recorded, despite your minimum age setting. This can happen if the recording software isn’t “locking” the file, making MCEBuddy think it’s ready for processing.

I found a few similar discussions that might help:

Even though you have it set to 3 hours, it might be worth trying to increase it further, or perhaps there’s a slight discrepancy in how the “last modified” time is being reported across your network shares and VM.

Could you share your MCEBuddy.log file? That would provide more specific clues as to what’s happening when MCEBuddy picks up the file.

Also, even though you’re using an older version (2.5.7), it’s generally recommended to keep MCEBuddy updated for bug fixes and compatibility improvements. Just something to consider if the issue persists.

3

您是否正在使用网络映射驱动器或共享驱动器？最小年龄是根据文件系统提供的最后修改时间戳计算的。

您可以检查以下几点：

  1. 您的虚拟机时间是否与存储录制文件的驱动器时间同步且正确。
  2. 检查存储录制文件的文件系统上的时间戳。如果它们不正确或未被更新，MCEBuddy 将仅将最小年龄加到最后的修改时间戳上，以计算何时开始转换。这可能表明文件系统存在问题。

已知有 NAS 产品的时间/时间戳不同步，从而导致此类问题。

4

是的，我检查过所有这些，或者说我以为我检查过了。当我登录到虚拟机时，我能在菜单栏上看到时间是 X:yy:zz，而文件写入的时间也是 X:yy:zz。但后来我检查了 Windows 机器上设置的时区，不知怎的（谁知道怎么回事）它被设成了 PST 而不是 EST（现在是 PDT/EDT 随便哪个哈哈）。把时区改回正确的之后，问题就解决了……就是这么一个简单的疏忽，但显示的时间把我搞糊涂了。我完全搞不懂 Windows（这就是我为什么不用 Windows……但也正因为这样我才需要一个虚拟机来跑 MCEBuddy 哈哈）是怎么做到显示的时间是对的，而当我改时区后，时间还是对的……但现在总算修好了。

5

並不是要搶功勞，而是想確認真正的解法有被記下來。正如 Goose 所說，關鍵是把所有時間都仔細檢查一遍，不只是檔案系統上的時間，還包括你電腦設定的時區。Emby 似乎會忽略時區（這也算合理，因為 Unix 檔案時間戳並不存 TZ 資料——附帶一提，NTFS 會存，所以「或許」在完整 NTFS 檔案系統且跨時區的情況下會有效……不過我懶得測啦）。重點是，程式邏輯看起來就是單純判斷「現在是否已超過 3 小時」；當你的本地系統時鐘落後 3 小時，檔案時間戳就會出現這種情況：本地時間是下午 1 點，但檔案戳記卻顯示下午 4 點，而我剛好選了 3 小時的延遲（主要是為了避免一次掃到 99% 的電影）。