www.makemkv.com

This problem started with 1.10.5 and 1.10.6 has not fixed the issue.
I use MakeMKV with the WDTV profile to extract movies from BDs that I own. This works fine.
Then I use HandBrake to condense the resulting file into something smaller.
Because Captions are not displayed while playing back the condensed file, I have to process the smaller file with MakeMKV and the WDTV profile.
Before version 1.10.5, this worked fine and the resulting MKV files played back fine through my WDTV box USB attached to a set of high capacity hard drives.
Starting with Version 1.10.5, this no longer worked. I reverted to 1.10.4 for processing the HandBrake compressed files.
I noticed a new version 1.10.6 and decided to give that a try.
Processing the BD discs worked fine and as expected.
Using HandBrake to reduce the size of the file worked fine and as expected.
Processing the resulting file with MakeMKV failed to complete (no errors), but a memory leak eventually used all available computer memory (12 G on Windows 7) and the process crawled to a stop halfway through the process.
I manually stopped the system.

Any ideas how to fix this, or is there a new WDTV profile that I need to install?

What is interesting is that the wdtv.mmcp.xml carries the same date as the makemkv.exe
This is the log:
Debug log started at Wed Jun 07 16:46:41 2017 , written by MakeMKV v1.10.6 win(x64-release)
Using 524544KB for read cache.
001005:0000 MakeMKV v1.10.6 win(x64-release) started
001004:0000 Debug logging enabled, log will be saved as C:\Users\Tom-Desktop/MakeMKV_log.txt
005011:0000 Operation successfully completed
005015:0000 Saving 1 titles into directory Q:/MakeMKV using profile 'WDTV' from file 'C:\Program Files (x86)\MakeMKV/wdtv.mmcp.xml'
005001:0308 File Q:/MakeMKV/PJ01_-_The_Lightning_Thief_t00.mkv already exist. Do you want to overwrite it?
004007:0010 AV synchronization issues were found in file 'Q:/MakeMKV/PJ01_-_The_Lightning_Thief_t00.mkv' (title #1)
004047:0010 AV sync issue in stream 1 at 0:00:00 : 0 frame(s) dropped to reduce audio skew to +21ms
004047:0010 AV sync issue in stream 2 at 0:00:00 : 0 frame(s) dropped to reduce audio skew to +21ms
001002:0020 LIBMKV_TRACE: Exception: Error while reading input
004008:0010 AV sync issue in stream 1,2 at 0:00:00 with duration of 21ms : encountered overlapping frame, audio skew is +21ms
005003:0000 Failed to save title 0 to file Q:/MakeMKV/PJ01_-_The_Lightning_Thief_t00.mkv
005004:0080 0 titles saved, 1 failed
005037:0204 Copy complete. 0 titles saved, 1 failed.
Application exited at Wed Jun 07 17:21:59 2017

Thanks for a great product. I can always go back to 1.10.4, but don't want to, since the current version seems to solve some BD reading problems that existed in earlier versions.

If you play the "raw" MKV file from the 1.10.5 and later rip, prior to handing it to handbrake, do things work?

If not, then mike will have to look at anything that changed in the WDTV profile.

Woodstock wrote:If you play the "raw" MKV file from the 1.10.5 and later rip, prior to handing it to handbrake, do things work?

If not, then mike will have to look at anything that changed in the WDTV profile.

Yes, at least on my computer. But I'll have to check a file on the WDTV device and get back on this.

The memory leak was a major issue. I do not remember if that was occurring with 1.10.5 or not, but it is something that I chanced to observed on 1.10.6 and that is what prompted me to report the problem here.

tomuser wrote:

Woodstock wrote:If you play the "raw" MKV file from the 1.10.5 and later rip, prior to handing it to handbrake, do things work?
If not, then mike will have to look at anything that changed in the WDTV profile.

Yes, at least on my computer. But I'll have to check a file on the WDTV device and get back on this.
The memory leak was a major issue. I do not remember if that was occurring with 1.10.5 or not, but it is something that I chanced to observed on 1.10.6 and that is what prompted me to report the problem here.

I just checked the raw MKV file for The NeverEnding Story (v.1.10.6) and it plays fine, with subtitles. (that can be switched off or on)

Handbrake works fine with PGS subtitles, so long as you're passing them through to the output file. If you're processing them (like pulling "forced only" titles out of a track, the resulting PGS will no longer be gzip-compressed, which is what the WDTV requires.

This is probably why you were doing a post-handbrake load in MakeMKV; you can do the same thing using mkvmerge from mkvtoolnix.download.

I remember reading about why handbrake can't compress PGS subtitles over on their forum, but I don't have a link to that.

Everyrhing worked without any problems with MakeMKV build 1.10.4. Then something changed. At this point, if I use MakeMKV build 1.10.5 or 1.10.6 after compressing the file with HandBrake, the system fails. I'm going to run another HandBrake-compressed file through MakeMKV 1.10.6 and be sure the save the log file. I'll post it here for analysis, but something major happened between .4 and .5 that caused the system to stop working correctly. As I said, I saw a major memory drain during .6's processing of the compressed file. That alone is a problem that needs to be looked at.

I did some additional testing with builds 1.10.5 and 1.10.4. I also captured the screen of the task manager for all three builds. The files are named with their build. All of these tests were run with the same HandBrake condensed file. It should be noted that Build 1.10.5 and 1.10.6 were able to process my BD discs.
I rebooted between builds. Once the maximum memory was being used by MakeMKV, the system did not want to exit the program. I had to hard restart the computer.
I attached the screen shots of the task manager during the failed attempts. (I uploaded them.)

Fastest way to get Mike to look at them is to email the information to support@makemkv.com .

Thanks. I'll do that.

I asked this question last year on the Handbrake forums, and got back the response:

The demuxer is doing it for us automatically. I'm not sure whether our muxer supports compressing them back or how to tell it to do so, TBH.

(From thread: https://forum.handbrake.fr/viewtopic.ph ... 59#p163653 )
and

The demuxer always has to uncompress the subtitles, else it couldn't provide the bitstream to us (a zlib-compressed PGS bitstream is not a valid PGS bitstream, the compression is part of the Matroska standard, not the PGS specification).

Eventually we may figure out how to tell the muxer to zlib-compress such subtitles tracks, but there are higher-priority items on ou respective TO-DO lists right now.

(From thread: https://forum.handbrake.fr/viewtopic.ph ... 59#p163671 )


AFAIK, there's still no in-built method in handbrake to recompress the zlib subtitles, but as Woodstock has mentioned, you can use the MKVToolnix to quickly process the file to re-compress the subtitles. As I was in the same boat, I've written a Powershell script for Windows that will parse a folder and all its subfolders, and will recompress the subtitles, if they are PGS subs and not already compressed. It's in the same thread, direct link to post (with software requirements etc) https://forum.handbrake.fr/viewtopic.ph ... 59#p165440