www.makemkv.com

First of all, if this (feature request(s)) are not allowed, please ignore and/or delete this post. Thanks.

1) About the generated .mkv files: They work well for playback, but at least the windows explorer can't access the video details, it displays only file-size and the timestamps. If i pass the generated file to mkvmerge with the following command-line arguments the file-size drops slightly (f.e. original: 5.145.935kb to 5.139.646kb) and now windows explorer is able to display duration, filesize, width, height, total-bitrate and framerate.

2) Playlist-(de-)scrambling: This feature might already exist, but if so, I don't know where and how to activate it. Modern series-blu-rays uses playlist-scrambling so the the episodes on the disc are not in the same order how they should be viewed. But most of this blu-rays also have the option to play all episodes instead of selecting each episode manually - so the information how the episodes should be viewed must be on the disc. Could this information be extracted/exported so it would be easier to keep the episode-playpack-order?

Currently i am doing the following: Export the episodes from disc, random order. Then i ran my mkvmerge script on this files to view the duration of the episodes in windows explorer. I could also start playback of the episode to get the duration, but if episode count increases the first approach is a little easier. Then i start playback of the blu-ray-disc, selecting each episode manually and look for the file with the same duration. If there are multiple episodes with the same duration, then I have to view them. I rename the file to match season/episode and start with the next episode.

Play list de-obfuscation requires you to have Java Runtime Environment installed, from Java.com. It does not always work, but, for most titles, it will move the most likely play list to the TOP of the selection window, and mark it as such.

Since I'm a former java-dev, i had multiple java-versions java7, java8, x86/x64 versions installed. No custom-java-executable defined in MakeMkv. Anyway, i removed all of them to install the new java 9 (which is only x64). Specified the java.exe of this new installation in MakeMkv and tried again. Nothing The order (from the filenames) is still wrong.

So is a specific java version or platform required? Is there a visual indicator (in the logs or elsewhere) that shows that a) the java version has been recognized and b) that de-obfuscation has been tried to accomplish (success/failure)? Are there other obfuscation types that MakeMkv can't handle, and if so, can they be detected?

Below is the export with the MakeMkv filenames as well as the true filenames as they should be viewed. I've tried to attach a screenshot of what MakeMkv has detected on the disc, but 'board attachment quota has been reached'.

If your disk is an episodic TV series, it is highly unlikely it is using playlist obfuscation, so you won't see MakeMKV trying to use Java to decode it. Lionsgate does not seem to be interested in screwing up the viewing pleasure of TV shows, just movies.

What you're seeing is a byproduct of how MakeMKV enumerates titles. It numbers them as it finds them in the directory, i.e., first title found is "00", second is "01", etc.

Most of the time, episodes will be numerically sequential file names on a disk. But, sometimes, they are not listed in the disk's directory in sequential order.

I was hoping to find one of my old messages that described some Funimation and Sentai Filmworks disks I've ripped, where the episodes were in order by file name (0005 through 0014), but their location in the directory was (from memory) 0014, 0012, 0011, 0010, 0005, 0009, 0008, 0006, 0007. With Expert mode enabled, I was able to use the "filename" information in the right hand detail window to assign them MKV file names in the correct order before the rip began.

Next time you open the disk in question, scroll through the titles and see if the file names are in sequential order... I've already submitted a feature request to (at least optionally) sort titles by file names.

For this disc (and hopefully the future ones) the source-file-name seems to be the correct order. hopefully we can set the source-file-name as filename by default in some future version. Thanks!