–Scheduled off-air recordings regularly made with nextPVR, saved to folder
–MCEBuddy watches this folder and converts new recordings, with commercials cut using Comskip, and then the original file is archived to another folder.
–The converted file is then placed in a different folder where it is visible to Plex.
However, I live in a fringe reception area. Most of the time, reception is good enough to yield a watchable recording, even if there are some skips or glitches. It’s something I have to live with, living where I do.
But, these glitches sometimes result in MCEBuddy being unable to successfully process the recording, even though the original recording file (with commercials) can be manually put in Plex’s folder where most of the time it can play it back without issues.
The problem is that if MCEBuddy cannot finish processing a recording, it tries endlessly. So if I leave my PC unattended, it ends up trying non-stop to convert a backlog of files, with the hard drive running constantly. In fact, this has led to two hard drives wearing out in the four years that I have had this workflow. (MCEBuddy/Plex run from a secondary internal drive, fortunately).
Is there any way to set MCEBuddy to not keep trying - if a conversion fails, simply let it stay ‘fail’ rather than an endless cycle of starting over and trying again?
It depends on what part of the conversion is failing.
If the remux is failing: the way MCEBuddy works is that it tries 4 times to remux with a different set of parameters. These are defined in the mcebuddy.conf file under the FFMpegBackupRemux section and you can see the difference between each try (starts from transcoding to eventually recoding to mpeg2)
If the conversion is failing: the number of reties depends upon how your profile is setup in profile.conf. Most profiles have 3 backups set under the order section. Handbrake, Ffmpeg and Mencoder. When one encoder fails it falls back to the next encoder and so on. So it should stop after 3 tries.
It will NEVER be an infinite number of tries, it’s basically defined by your setup as given above. So you can customize it e.g. remove (or add more) lines to the FFMpegBackupRemux section if remux is failing or remove encoders you don’t want in the profile under the order command
The folder contains 77 log items, where MCEBuddy repeated every 10-15 minutes from 9:55 AM 2017-06-19 until the loop was stopped by manually moving the recording to another folder at approximately 7:27 AM 2017-06-20.
Thanks for the logs. This is different from what I had posted about about fallback conversions. This appears that the engine is restarting the entire conversion which shouldn’t happen.
Need the mcebuddy.log file - that log will show why the engine is restarting the conversion from scratch each time.
I’m uploading everything now. It’ll take about 20 minutes to complete and then you should have the mcebuddy.log file, the original .ts file, as well as the individual episode logs sent previously.
Okay thanks for the logs and sample files. So let me address two points your raised:
When you video recording is corrupted, subtitle extraction fails and the conversion fails - that’s by design, the idea being if anything “fails” you want to let the user know - especially since you may have delete original or something seriously impacting setting enabled which can have adverse side effects, hence if anything “fails”, the conversion will fail by design. You can go back in and manually reconvert those files or set the option to move failed files to a new folder and then process them with a separate monitor task and conversion task (e.g. don’t extract subtitles). The idea to let the user be in control and define rules on how to handle exceptions rather than assume.
Coming to your main issue, the infinite conversion loop. The issue is with the way you’ve configured MCEBuddy. You’ve literally asked MCEBuddy to monitor your files, converted and original indefinitely. See this configuration from the logs, I’ve highlighted the settings where your Monitor Task (Expert Settings) is configured to indefinitely reprocess files. ALSO: Your archive folder path is invalid, you’re missing a slash \ after E:. Since your original file already exists in the Archive folder, it doesn’t move the file and the way you’ve configured MCEBuddy you’ve asked it to reconvert every file in your monitor folder indefinitely, even if it already been converted (in your case it converted but failed to move the original file to the archive folder for the reason given above).
MONITOR TASK OPTIONS ==>
Task → Windows Default
Search Path → E:\Recorded TV
Monitor Delete Original → False
Monitor Archive Original → True Monitor Archive Folder → E:MCEBuddy2x\MCEBuddyArchive ← Missing a \ after E:
Monitor SubDirectories → True Monitor Converted Files → True ← Asking MCEBuddy to convert your converted files (why??) ReMonitor Recorded Files → True ← Asking MCEBuddy to reconvert your original recording which have successfully converted, this is why you’re in an infinitely loop. (Why??)
EDIT: In the next release the default behavior of Archive and Failed will be changed to overwrite any existing files so that it doesn’t fall into the trap of failed loops like above.