So I seem to consistently get this message. I can get things to work, if I copy everything to a local drive, but it seems reading from the fileserver causes this problem. I’m seeing ~100MB/sec read performance from my NAS, which isn’t horrid. Log file attached.
Wondering if something is going to sleep, and then not waking up. Also, I saw I could increase the ffmpeg kill time. What’s it expecting to happen in 5 minutes? That seems like a bit of time.
This log shows that you’ve cancelled the conversion
ERROR> 2019-08-18T12:00:06 MCEBuddy.AppWrapper.FFmpeg → Job cancelled, killing process
However what you’re describing is not uncommon. To avoid the possibly to a being “hung” by a faulty process, if MCEBuddy doesn’t seen a process responding for 300 seconds (by default) it kills it and moves onto the next file.
If you’re using a network drive/NAS and if it’s running slowly and takes more than 300 seconds, it could lead to this timeout. If you know that’s your network or computer is slow you can increase this timeout or even disable it by setting it to 0 in the System Settings page
Simply haven’t had the time to go back and fight this. Can you talk a little more about what the 5 minute FFmpeg timeout is for? Is it for complete ffmpeg pass completion (if so that seems short) or are you just waiting for some sort of text output message?
Yes, just anything to show that it’s still working and not hung for waiting for something indefinitely (there’s much more advanced detection in there, but that’s the gist of it).
OK. Needed to do a full Windows 10 reinstall for unrelated reasons, and I finally tried again. From this log file, it looks like things were happy, and it loses the SMB connection and can’t find the file? Is increasing the 5 minute timeout going to help?
From your logs it doesn’t seem to have anything to do with your network, it’s your C drive that’s not responding. Sounds like you may have a bad hard drive (either there MCEBuddy is installed since the executables and temp folder are both located in the same drive/folder):
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Launching process C:\Program Files\MCEBuddy2x\handbrake\handbrakecli.exe
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Process arguments -i “C:\Program Files\MCEBuddy2x\working0\Childhood’s End_Syfy_2015_12_16_15_58_00.ts” --loose-anamorphic --verbose=2 -f mp4 -O --start-at duration:0 -e x264 -b 3733 -x me=hex:trellis=1:subq=8:partitions=all:8x8dct:ref=3:rc-lookahead=50:keyint=25:keyint-min=20:bframes=1:weight-b:level-idc=40:b-pyramid=normal:direct-pred=auto:mixed-refs:deblock=-1,-1:nofast-pskip:nodct-decimate:b-adapt=0:threads=auto --crop 0:0:0:0 --disable-qsv-decoding -E faac -R auto -B 256 -D 2.5 -a 1,2,3,4,5 -6 6ch -o “C:\Program Files\MCEBuddy2x\working0\Childhood’s End_Syfy_2015_12_16_15_58_00-converted.mp4”
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → UI Session Admin Process : True
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Starting process as a UISession process with Admin privileges. This requires atleast 1 user to be logged into the system (remote desktop or locally)
2019-09-19T18:16:11 MCEBuddy.AppWrapper.Handbrake → Setting process priority to Normal
ERROR> → No response from process for 300 seconds, process likely hung - killing it
ERROR> → Process hung, killing process
Hmm… not out of the question given some other behavior I’ve observed, but various SSD test utilities aren’t seeing anything. Is there an option to leave the intermediate files in the working0 directory after failure?
So the final solution here seemed to be to disable sleep in my Windows Power settings. Note I did NOT ever check the “Allow Sleep” setting in MCEBuddy.
FWIW: This is all running on a Surface 4, i7-7660U 16GB, Win 10 Pro 1904 B 18362.418
