MKV Unprocessed stops during MCEBuddy.RemuxMediaCenter.ExtractWithGraph

Converter using an MKV unprocessed profile from a 90 minute wtv file. For some reason, the remux stops after 25%, with no sign of errors. End product is in fact only 25% as long (in minutes) as the original.

2018-06-16T21:49:15 MCEBuddy.RemuxMediaCenter.ExtractWithGraph → Percentage complete : 24.98 %
2018-06-16T21:49:31 MCEBuddy.RemuxMediaCenter.ExtractWithGraph → Percentage complete : 24.99 %
2018-06-16T21:49:31 MCEBuddy.RemuxMediaCenter.ExtractWithGraph → Source D:\Recorded TV Test\The Sing-Off_WDIVDT_2011_12_05_19_58_00 - DVRMS.dvr-ms filesize [KB] : 9,371,702.00
2018-06-16T21:49:31 MCEBuddy.RemuxMediaCenter.ExtractWithGraph → D:\temp\working0\The Sing-Off_WDIVDT_2011_12_05_19_58_00 - DVRMS_AUDIO0 extracted filesize [KB] : 65,095.00
2018-06-16T21:49:31 MCEBuddy.RemuxMediaCenter.ExtractWithGraph → D:\temp\working0\The Sing-Off_WDIVDT_2011_12_05_19_58_00 - DVRMS_VIDEO extracted filesize [KB] : 2,276,579.00
2018-06-16T21:49:31 MCEBuddy.RemuxMediaCenter.ExtractWithGraph → Total extracted parts size [KB] : 2,341,675.00

I’ve tried this a couple of times with the same results. Any suggestions?The Sing-Off_WDIVDT_2011_12_05_19_58_00 - DVRMS.dvr-ms-MKV Unprocessed-2018-06-16T21-40-36.9237008-04-00.log (1.0 MB)

The Sing-Off_WDIVDT_2011_10_17_20_10_20 - DVRMS.dvr-ms-MKV Unprocessed-2018-06-16T22-19-16.8683941-04-00.log (737.7 KB)

Here is another log file from a different source file that shows the same behavior.

Checked out the logs, noticed one thing about the video stream - not sure how relevant it is but the stream does have an issue:

2018-06-16T21:41:23 MCEBuddy.AppWrapper.Base → [mpeg2video @ 000000000053ad60] Invalid frame dimensions 0x0.

That being said, for DVR-MS, MCEBuddy has windows directshow codecs process and extract the raw video and audio files.
In your case, the windows codes are only returning the first 25% of the file. That most likely means that the file has an EOF (end of file) marker in there around the 25% mark and windows thinks it’s the end of the stream. This usually means a faulty tv tuner/recording driver (it happens with some buggy drivers). Try to update your driver.

There are other way MCEBuddy can extract the steams but those will kick in only if the windows stream codecs “fail”, in this case it doesn’t fail but it’s returning a success code with only 25% of the stream likely due to the EOF.
If you can upload the original DVR-MS file we can check it out.

I put up two files to the ftp server, in a folder named klaberte. Both of them “prematurely completed”, one near 25%, the other near 16% (IIRC). Please let me know if you find any issues with the source files. Thanks!

Check it out, the file definitely has issues, even FFMPEG failed to remux it so it’s no surprise that Windows DirectShow codecs also had an issue. This indicates that your recording device driver has a problem with creating compliant streams (it could be a bad air stream reception also).

2018-06-21T16:26:23 MCEBuddy.AppWrapper.FFmpeg → error, non monotone timestamps 286588800 >= 286585920
2018-06-21T16:26:23 MCEBuddy.AppWrapper.FFmpeg → error, non monotone timestamps 286588800 >= 286588800
2018-06-21T16:26:23 MCEBuddy.AppWrapper.FFmpeg → error, non monotone timestamps 286632000 >= 286629120
2018-06-21T16:26:23 MCEBuddy.AppWrapper.FFmpeg → error, non monotone timestamps 286641090 >= 286641090

However, there is a special dvrms remuxer that MCEBuddy users which was able to remux it just fine. The issue is that Windows DirectShow doesn’t return an error so MCEBuddy doesn’t use the special remuxer.

You can try converting it on a windows machine which doesn’t have the DVRMS codecs (e.g. Windows 10) or you can download today’s 2.4.9 BETA build and add this new setting to your profile:

DisableDVRMSStreamsRemuxing=true

This will make MCEBuddy skip using the Windows codecs for stream remuxing the DVRMS files and jump to using the ffmpeg and then the special remuxer (ffmpeg will fail here, so the special remuxer will kick in)

Thank you! DisableDVRMSStreamsRemuxing=true seems to have fixed that issue!

If I am using an MKV unprocessed profile, is DisableDVRMSStreamsRemuxing=true still a good work around on my Win7 machine?

It’ll work with any machine, we generally advocate using Windows streams remuxing as the first preference as its’ faster and has native advantages but this workaround will work for any machine that has trouble with streams remuxing like you did (but no failure codes).