Converting converted files

Ever since upgrading to version 2.5.7 I have noticed an occasional conversion that runs more than once, without a “period”. Last night, The Blacklist and a Hallmark movie ran more than once. I have attached the logs for review.
Thank you.
mcebuddy.zip (333.0 KB)

Moving this to a new topic, thanks for the logs. We’ve identified the potential source of why some of your converted files are getting into a conversion loop caused a race condition when the system is under heavy stress.

This has been fixed in today’s 2.5.7 BETA build, try it out and let me know if you’re still having issues.

I will let you know if it happens with the new build. Thank you.

@Goose
I experienced another conversion loop last night. Here are the logs.
Thanks,
dcmcebuddy.zip (163.3 KB)

Okay, I think we found a potential race condition where the monitor location was picking up the new file before the engine could record the converted file. We’ve put in a fix for it. Try todays’ 2.5.7 BETA build and this should fix it now.

Thank you, I will install the new build today.

@Goose
Please see the attached logs from last nights dual conversion.
Thanks,
djc
mcebuddy.zip (69.1 KB)

Hmm, okay we think we know what’s going on and it’s has something to do with your network filesystem reporting an incorrect status throwing MCEBuddy off.

So what’s happening is that your destination folder is a network folder. The original file is about 5GB in size it’s takes a long time for the file to be moved to the destination network folder, which also happens to be your source folder which is being monitored by the Monitor location. So when the converted file is being copied, if at that specific moment the Monitor task decides to scan your folder the new converted file shows up. Ideally a normal system will report the file as being written/locked so MCEBuddy skips it. For some reason your network file is reporting the file as ready for reading, which misleads MCEBuddy to think it’s available and it ends up adding it to the queue.

We’ve put in a fix for it to handle such filesystems which may report an incorrect file lock status so with today’s 2.5.7 BETA build it should be handled.

For reference, the alternative way to fix this would be to increase the Minimum age of the file in the Monitor Task advanced settings (default 1 min - in your case it took over 1 minutes to complete the copying process) to say 30 minutes. What this does is even if the file system incorrectly reports that the file is ready (when it’s actually locked for writing), MCEBuddy will wait 30 min before adding to the queue, by which time the conversion will be completed and the databases updated so when 30 minutes passes it’ll register as already converted and it’ll skip it.

I will try the new version and increase the minimum age time tomorrow. I do have a question however, since this issue only started when the problem with the file name ending in a period was corrected, why is this happening now?

Prior to that fix I only experienced this problem when the file name ended with a period.

I really appreciate all of your assistance.

1 Like

These are two completely different and unrelated issues. The first was a bug in how the period was handled (ignored by windows but not by mcebuddy) causing a filename mismatch.

The second is a race condition that happens under just the right circumstances (the monitor task has to run a scan just when the file is being moved) and possibly brought on by a change in how your network fileystem is reporting (or not) locked files.

With this update you shouldn’t have to increase the minimum age. Try that first just to confirm that it’s working as expected.

So far there have been no issues to report.