Conversion task ignoring minimum age

I took some time to validate that mce buddy was working correctly in my setup (network shares many recordings happening, MCE buddy running in a vm and so on) then decided i was safe to turn it on. the one thing i did not test was the minimum age before processing. I set it at 3 hours and went to bed… (i did not have any recordings scheduled for about an hour so i did not want to wait. When i checked today… all my recordings were 1 minute long. it took me some time to realize that it must be mcebuddy… and then i did some testing and sure enough mce buddy starts processing the file 1 minute after it starts recording (maybe by chance at the poll interval)

Clocks are all synced and so on.

Any clues?

MCE Buddy Version 2.5.7 (im a bit loathe to pay for a newer version when the older version had been working before. and i just got another provider for recording)

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.

Are you using a network mapped drive or a shared drive? The minimum age of the is calculated from the last modified timestamp as provided by the file system.

You may want to check a few things:

  1. If the time on your virtual machine in sync and correct with the time on the drive where your recordings are being monitored.
  2. Check the timestamps on the fileystem where the recordings are stored. If they are incorrect or aren’t being updated then MCEBuddy will just add the minimum age to the last modified timestamp to calculate when then to start the conversions. This may indicate an issue you the file system.

There haven know instances of NAS products who have their time / timestamps out of sync which creates such issues.

Yes i checked all that or thought i had anyway. when i logged in to the vm i could SEE on the menu bar the time was X:yy:zz and the time the file was written it was X:yy:zz BUT then i checked the time zone set on the windows box and SOMEHOW (who knows how) it was set to PST vs EST (PDT/EDT whatever it is now lol) switching that to the correct time zone fixed it all… so simple of a miss but the time displayed was messing me up. Not at all certain how windows (this is why i dont use windows… but also why i need a vm to run mcebuddy hehe) managed to display a time that was correct and when i changed the time zone it was still correct… but now it is fixed

and not taking credit FOR the solution but wanted to make sure that the actual solution was noted. the solution was as Goose mentioned a critical look at all the times not just on the filesystem but the timezone your computer is set to it seems emby ignores the time zone (thats reasonable I suppose since unix does NOT store TZ data in file timestamps - as a note NTFS does so MAYBE it would work on a total NTFS file system with different time zones… not gonna test lol) but the point being that it looks like it does just say is it now more than 3 hours… and the file stamp on the file when your local system clock is 3 hours behind… welll its 1PM local but the filestamp will show 4PM and i happened to select a 3 hour delay (mostly to make sure i dont mow over 99% of the movies)