Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Manni]

I have two questions about UHD Bluray support:

1) When I play a title in JRiver, the time between drop frame is initially very short. It goes up, but I don't understand why the stats are so much worse than using the same install (LAV+madVR) with MPC-BE. With BE, I get to 2 hours between frame drops in a few minutes, and when it starts it's at least a few minutes. With JRiver, it's a few seconds at most initially, and it takes ages for it to go up to say 20 minutes or so. The performance otherwise is the same (queues are full, rendering times are simila etc). It's the same custom settings, from the same installation of LAV and madVR (from the plugin folder in JRiver). Any other install has been un-registered and uninstalled.

2) I'm using measurements files with madVR to improve HDR tonemapping. They are working great with .mkv files with MPB-BE, but I'd like to use them with BD Folders to get them to work when I use UHD Bluray menus with JRiver. If I identify the main playlist and measure it with madMeasureHDR, I get measurements files taken into account when playing the folder in MPC-BE. But if I play the same folder with JRiver, the measurements files are not taken into account. Even if I play the title in movie only (without the menus), I can't get madVR to use the measurements for the main .mpls file. Is there a way to know which playlist/file is JRiver playing? When there is a main/default .mpls, it it what JRiver is playing? I also tried to measure the main .m2ts file, but that doesn't make any difference: no measurements taken into account by madVR. Of course the measurements files are enabled in madVR, and I checked the active profile: it's the same in MP{C-BE and JRiver (same as above, no other installation of LAV or madVR, same settings for both).

In case it matters, I'm using D3D11 copyback during playback (native doesn't work with most UHD bluray menus and I need black bars detection).

Thank you for your help!

[Hendrik]

1) When I play a title in JRiver, the time between drop frame is initially very short. It goes up, but I don't understand why the stats are so much worse than using the same install (LAV+madVR) with MPC-BE. With BE, I get to 2 hours between frame drops in a few minutes, and when it starts it's at least a few minutes. With JRiver, it's a few seconds at most initially, and it takes ages for it to go up to say 20 minutes or so. The performance otherwise is the same (queues are full, rendering times are simila etc). It's the same custom settings, from the same installation of LAV and madVR (from the plugin folder in JRiver). Any other install has been un-registered and uninstalled.

Are there actually any drops, though? Outside of right at the start of playback, of course.
The stats are only estimates and known to be rather weird in many cases.

2) I'm using measurements files with madVR to improve HDR tonemapping. They are working great with .mkv files with MPB-BE, but I'd like to use them with BD Folders to get them to work when I use UHD Bluray menus with JRiver. If I identify the main playlist and measure it with madMeasureHDR, I get measurements files taken into account when playing the folder in MPC-BE. But if I play the same folder with JRiver, the measurements files are not taken into account. Even if I play the title in movie only (without the menus), I can't get madVR to use the measurements for the main .mpls file. Is there a way to know which playlist/file is JRiver playing? When there is a main/default .mpls, it it what JRiver is playing? I also tried to measure the main .m2ts file, but that doesn't make any difference: no measurements taken into account by madVR. Of course the measurements files are enabled in madVR, and I checked the active profile: it's the same in MP{C-BE and JRiver (same as above, no other installation of LAV or madVR, same settings for both).

You would have to ask madshi how it tries to find such files. We cannot really support pre-release madVR versions here.

[Manni]

Thanks for the quick reply.

Yes, there are some drop in the first minute when playing with JRiver. Never with MPC-BE.

I know the stats are estimates, still it shows that something is different in the playback and I can’t understand why given that the settings and install for LAV and madVR are the same.

Re measurements files, I understand you can’t support test builds of madVR, but my question was about the file played by JRiver. Say that if you drop a BD folder in MPC-BE it parse the folder and decides that the main file is 00800.mpls. Is JRiver likely to play that .mpls file too when playing the same BD Folder, or is the process different? I haven’t tried to but I could do a movie only rip of a title with DVD Fab (so a single .mpls and a single .m2ts) to verify this. I kind of need to know which file JRiver is playing before I go back to Madshi, or he’s going to ask that question. If it’s not the .mpls and not the .m2ts, what is played internally in JRiver?

Thanks again for your help.

[Hendrik]

In title playback LAV Splitter is used like in any other player. It should always play a specific .mpls file, either of the title MC deems the main title, or the one you selected. It should never play a m2ts directly, unless you specifically tell it to.

Note that with menus, you're probably out of luck, since its not one title, and due to its interactive nature, also not consistent. Ideally madVR would have to figure out where titles change, and which title is currently playing, and I faintly remember talking to him about that briefly, but I don't think anything ever came of it yet.

[Manni]

Thanks a lot for the confirmation that the main .mpls title should be played. It’s definitely what happens in MPC-BE. It’s probably what happens with MC too but in that case madVR can’t find the file. Understand the difference when menu playback.

It we could get main movie only to playback properly, it would already be progress.

I’ll discuss this with Madshi and will point him to this thread. Thanks again for your help.

[mattkhan]

Thanks a lot for the confirmation that the main .mpls title should be played. It’s definitely what happens in MPC-BE. It’s probably what happens with MC too but in that case madVR can’t find the file. Understand the difference when menu playback.

It we could get main movie only to playback properly, it would already be progress.

this works for me once I copy the measurements file to the right place

i.e. if the main feature is played by PLAYLIST/00800.mpls then you can measure index.bdmv which will create index.bdmv.measurements and then copy that to PLAYLIST/00800.mpls.measurements and madvr will now use the measurements file

[Manni]

That's great thanks, I'll try that

[Manni]

this works for me once I copy the measurements file to the right place

i.e. if the main feature is played by PLAYLIST/00800.mpls then you can measure index.bdmv which will create index.bdmv.measurements and then copy that to PLAYLIST/00800.mpls.measurements and madvr will now use the measurements file

It's working fine thanks!

EDIT: although only in main movie playback. If playing with menus, then measurements files are not used. Please can you confirm that's what you see as well? Thanks.

[Hendrik]

If you open the MPLS directly for measuring, I would think it would also write that file directly without requiring a rename, no?

[Manni]

If you open the MPLS directly for measuring, I would think it would also write that file directly without requiring a rename, no?

I just did more testing and it's the opposite. You don't need to copy the index.bdvm.measurements file, the index.bdmv.measurements is enough.

But you need that one. Having only the 00800.mpls file doesn't work, I tried that yesterday.

That's good news, it means it can be automated!

[EDIT: you actually need both if you also use MPC-BE. JRiver needs the index.bdmv one and MPC-BE needs the 00800.mpls one.]

The only issue is that it works only in main movie mode. If you use the menu, the measurements files are not used.

[mattkhan]

I have never seen madvr use the index.bdmv.measurements , it is always the MPLS one that it uses. Odd that it is different in your case. I wonder what causes that?

I haven't found a way to automate this though as I have not come across a tool that can output the MPLS from the index.bdmv, is there one?

btw there was earlier discussion on this subject https://yabb.jriver.com/interact/index.php/topic,118026.msg816521.html#msg816521

[Hendrik]

JRiver needs the index.bdmv one [..]

I can't reproduce that at all, and I also wouldn't know where that would come from. That file is never really used, it'll always refer a MPLS file to LAV Splitter, as such thats the file name madVR gets to see.
In fact, I just tried it out as well, since I was curious, and I analyzed Avengers 3 UHD, 00800.mpls, now with 00800.mpls.measurements, and the data shows up fine in the OSD.

Speaking of the other thread, I actually implemented the change we talked about there, I'll let madshi know once a build with it included is public.

[Manni]

I have never seen madvr use the index.bdmv.measurements , it is always the MPLS one that it uses. Odd that it is different in your case. I wonder what causes that?

I haven't found a way to automate this though as I have not come across a tool that can output the MPLS from the index.bdmv, is there one?

btw there was earlier discussion on this subject https://yabb.jriver.com/interact/index.php/topic,118026.msg816521.html#msg816521

Thanks, that thread was a very useful read.

No I don't know of any tool, but I've just updated my batch file to automatically measure index.bdmv files. As there is only usually only one of these that is measurable per title, it means you can automate the measurements of all the index.bdmv files (I'm doing this right now). However you still have to manually copy the file as .mpls to the playlist folder.

[Manni]

I can't reproduce that at all, and I also wouldn't know where that would come from. That file is never really used, it'll always refer a MPLS file to LAV Splitter, as such thats the file name madVR gets to see.
In fact, I just tried it out as well, since I was curious, and I analyzed Avengers 3 UHD, 00800.mpls, now with 00800.mpls.measurements, and the data shows up fine in the OSD.

Speaking of the other thread, I actually implemented the change we talked about there, I'll let madshi know once a build with it included is public.

I have no idea why, I can only report what I observed. Before posting in this thread, I measured the 00800.mpls and that would work fine for MPC-BE but not for JRiver.

I'll try to rip the Avengers 3 (Infinity War?) and I'll report back.

If just the .mpls file works for you, I need to identify why. It could be connected with my poor stats in JRiver reported above.

What I've done is the following:

- uninstalled all standalone versions of LAV
- registered the LAV64 version in the JRiver plugin directory
- registered a LAV32 version in a LAV32 folder I created in the JRiver plugin directory, so that madmeasureHDR can work (I think it needs lav32)
- de-register my exiting version of madVR and registered the one in the madvr folder in the JRiver plugin directory.
- I don't use the settings.bin for madVR, only the registry settings (I delete the settings.bin file when I see it).

As far as I know and as far as I can see, I only have the versions in the plugins folder active, and they are sharing the same settings with JRiver and MPC-BE.

Do you see anything wrong with this?

If you think I should "reset" this installation, how do you suggest I do this and how do you recommend I set it up so that say MPC-BE and JRiver share the same settings and the same installation of madVR and LAV? Or it is recommended they use different installations?

[Manni]

Thanks, that thread was a very useful read.

No I don't know of any tool, but I've just updated my batch file to automatically measure index.bdmv files. As there is only usually only one of these that is measurable per title, it means you can automate the measurements of all the index.bdmv files (I'm doing this right now). However you still have to manually copy the file as .mpls to the playlist folder.

Are you on MC24 or MC25? I tried installing MC25 but it kept crashing on start, so I reverted to MC24. Maybe there is a different behaviour in MC25?

[mattkhan]

Are you on MC24 or MC25? I tried installing MC25 but it kept crashing on start, so I reverted to MC24. Maybe there is a different behaviour in MC25?

I am using MC25

it was the same for me in 24 though

[Manni]

I am using MC25

it was the same for me in 24 though

Sure but you're not saying like Nev that index.bdmv isn't necessary for JRiver and that measuring the main .mpls file is enough?

If you need to create the 800.mpls measurements file, I wonder if you need the index.bdmv measurements though, or I'm not sure why.

What Nev describes (that only the 800.mpls mesurements is needed) makes more sense, that's what I tried to do in the first place, but that didn't work for me.

Anyway, I'm unistalling everything, cleaning registry and installing MC25 with Red October HQ default settings for everything.

Then I'll see if I can reproduce what Nev is reporting, which has never worked for me.

And if it does work like this, I'll try to upgrade things one by one, to see if any of my existing settings (I saved my registry sections for LAV and madVR) break something.

[Manni]

I can't reproduce that at all, and I also wouldn't know where that would come from. That file is never really used, it'll always refer a MPLS file to LAV Splitter, as such thats the file name madVR gets to see.
In fact, I just tried it out as well, since I was curious, and I analyzed Avengers 3 UHD, 00800.mpls, now with 00800.mpls.measurements, and the data shows up fine in the OSD.

Speaking of the other thread, I actually implemented the change we talked about there, I'll let madshi know once a build with it included is public.

I uninstalled everything, cleaned registry and installed MC25 from scratch (no crash on startup anymore).

Maybe the issue came from having both MC24 and MC25 installed, even if I was only using MC24?

Anyway, with this clean install of MC25, I see the same behaviour as you: the measurement of index.bdmv isn't needed. Measuring the main playlist (00800.example) is fine.

[mattkhan]

Sure but you're not saying like Nev that index.bdmv isn't necessary for JRiver and that measuring the main .mpls file is enough?

If you need to create the 800.mpls measurements file, I wonder if you need the index.bdmv measurements though, or I'm not sure why.

I've only ever said that the 00800.mpls is what is required (in the original thread and this one) but probably confused matters with mention of index.bdmv

I measure index.bdmv and then copy it because it is the file that is always present in the same location so is easy to script. You can then work out later which file you actually need. If there was a way to find this ahead of time then I'd search on that basis instead.

[Manni]

I've only ever said that the 00800.mpls is what is required (in the original thread and this one) but probably confused matters with mention of index.bdmv

I measure index.bdmv and then copy it because it is the file that is always present in the same location so is easy to script. You can then work out later which file you actually need. If there was a way to find this ahead of time then I'd search on that basis instead.

Yes, then we agree

By the way it's not always the same file. For example, I've just measured American Assassin, and for some reason when parsing index.bdmv MPC-BE returns 00802.mpls, so that's the file measured if you measure index.bdmv. But JRiver doesn't play that file, it plays 00801.mpls, so that's the file to measure in that case for JRiver.

I agree though that measuring index.bdmv in a script is the way to go, that's what I'm doing in mine, but you do need to double check with the actual player(s) you intend to use as it might be necessary to measure more files.

Thanks again for your help (and Hendricks) resolving this!

[Manni]

I can't reproduce that at all, and I also wouldn't know where that would come from. That file is never really used, it'll always refer a MPLS file to LAV Splitter, as such thats the file name madVR gets to see.
In fact, I just tried it out as well, since I was curious, and I analyzed Avengers 3 UHD, 00800.mpls, now with 00800.mpls.measurements, and the data shows up fine in the OSD.

Speaking of the other thread, I actually implemented the change we talked about there, I'll let madshi know once a build with it included is public.

Okay, with my step-by-step debugging I was able to reproduce what causes this, and so should you.

As soon as I try to add some custom rules above Red October HQ, the .mpls measurements are not recognized anymore by JRiver.

I needed to do this to be able to enable the tray icon for LAV splitter, video and audio, as the standalone settings apps are not available when using the JRiver plugins.

So the question is: if you can't add LAV as custom rules, how do you change LAV settings when the standalone version isn't installed?

Or is it fine to have the standalone version installed as well for all the other software, and to keep the plugin version just for JRiver?

[Hendrik]

If you overwrite the Source filter, you take control away from Media Center, so it didn't actually do its playlist selection and just passed the index.bdmv to the filter.
However, I've just done a change for MC25 so that it'll still do the title selection, and still pass the appropriate playlist to the custom source filter selected.

It should show up in a future build.

[Manni]

If you overwrite the Source filter, you take control away from Media Center, so it didn't actually do its playlist selection and just passed the index.bdmv to the filter.
However, I've just done a change for MC25 so that it'll still do the title selection, and still pass the appropriate playlist to the custom source filter selected.

It should show up in a future build.

Great thanks, glad we got to the bottom of this!

[Manni]

Just to confirm that the latest build works fine with custom filters and the measurements file is loaded with the main movie.

Thanks for fixing/changing this!

Is the parameter needed by madshi to detect file change when using menu playback implemented in a public build yet?

[Hendrik]

Is the parameter needed by madshi to detect file change when using menu playback implemented in a public build yet?

Yes, its also in 16, and I notified him. But it'll probably be a while on account of Envy before something happens.

[Manni]

Yes, its also in 16, and I notified him. But it'll probably be a while on account of Envy before something happens.

Thanks, that’s great.

[mattkhan]

in lieu of madshi picking up the changes from you, I wrote a little utility to find the main title using libbluray and move the measurement files around accordingly (https://github.com/3ll3d00d/madmeasurer/releases). As a result, I have found myself going down a bit of a rabbit hole as it seems every app does it slightly differently.

* LAVSplitter (BDDemuxer) looks at duration only
* the mpc-be code[/code] picks the track with that highest video resolution that is within 50% of the duration of the currently selected "main" track

There are then at least 2 versions of libbluray out there, the mainline one at [url="https://code.videolan.org/videolan/libbluray/blob/master/src/libbluray/bdnav/navigation.c#L324"]videolan and your (Hendrik) version over at git://git.1f0.de/libbluray.git

All 4 options give different results quite often which makes writing this utility more tricky than I was expecting

Anyway I can't tell from the jriver logs what it actually does but, from limited testing, the results are consistent with your fork of libbluray. Is this correct?

As an aside, I see the difference is in this bit... i.e. your fork does not have this

Code: [Select]

    /* prefer playlist with higher number of tracks */
    int sc1 = _pl_streams_score(p1);
    int sc2 = _pl_streams_score(p2);
    return sc2 - sc1;

My tests suggest the mainline libbluray gets it wrong a fair number of times vs the other versions, any idea why they don't change it? are there some other cases that this code gets right?

[Manni]

Great utility, but my understanding is that Madshi needs to change his code so that he can detect the name of the mpls playing when using menus, otherwise it can’t load the correct measurements file.

Just played The Spy Who Dumped Me, the main title title wasn’t detected by MPC-BE and while it was detected in JRiver (main title, not menu), the measurement file wasn't loaded, so your utility had not detected the correct mpls to measure with libbluray.

Question for Hendrich: how can we get JRiver to display the path/name of the playlist it is playing? I tried to add custom fields but I could only get fake names (index.bdmv;1), not the actual .mpls to be displayed, the way you can in MPC-BE.

[mattkhan]

your utility had not detected the correct mpls to measure with libbluray.

This is exactly why I am asking what logic is used in jriver as every app does it slightly differently, mind you even then it is no guarantee to be the right one so you might end up having to brute force the measurements anyway. If you want to do this unattended that is, probably sufficient to just measurement the longest tracks in that case though, perhaps even with a lookup to find the official track length to minimise the redundant measurements

[Hendrik]

Media Center uses a bit more complex logic then that. It first looks at duration, and then when it found the longest titles, it'll compare those that are close in duration (within 10%, I believe), and prefer the one with the most audio streams.
This helps to weed out those titles with interleaved commentary scenes, since they typically have less audio streams, but are slightly longer.

In addition to that, it'll also look at the AnyDVD disc.inf file, which helps to fix discs with playlist obfuscation, which seems to only exist in the US, I have never seen one myself.

We'll probably put the title MC picked in some field in a future build, not decided yet where exactly.

[Manni]

This is exactly why I am asking what logic is used in jriver as every app does it slightly differently, mind you even then it is no guarantee to be the right one so you might end up having to brute force the measurements anyway. If you want to do this unattended that is, probably sufficient to just measurement the longest tracks in that case though, perhaps even with a lookup to find the official track length to minimise the redundant measurements

Yes, I was only providing an example where the current logic fails

Looking at the track length is a good idea if the length is different, but it's not always the case, thanks for the suggestion. By the way a max length in your utility would be useful when measuring all files, because some tracks are much longer than the main movie (often twice as long). Sometimes for TV series it has the length of all the episodes on the disc, or with some bonus discs even longer.

Hendrick, thanks for considering adding the .mpls track picked in a future build, it will be very useful.

I've checked a few disc.inf and I haven't seen any playlist obfuscation for UHD Bluray yet, it seems to be only used for bluray at the moment. Usually with UHD bluray the disc is the same for all regions to limit manufacturing costs, so it tends to be the same protection wordlwide as they are region-free.

[Manni]

By the way, one last thing that might be useful to identify the main playlist, would be to look at the track description comment. In quite a few movies, this comment includes "MainFeature".

For example, in The Spy Who Dumped Me, 3ll3d00d's libbluray algo detected 00804.mpls (which is also the file detected by MPC-BE, so it's not pointless to measure it), but it's not even listed by makemkv when opening index.bdmv.

The track listed is 00803.mpls, and it includes (FPL_MainFeature) in the description comment.
The only other large file listed by makemkv for this title is 00278.mpls (same length), identical to 803 but without chapters or comment in the description.

In that case, all three tracks have the same length, the main difference is comment in description and chapters.

[mattkhan]

I don't have that one but if you run with -vvv then the logging will say why it has picked the playlist it did. When all other things are equal, the way the libbluray algorithm is written means it tends to picking the "latest" (i.e. highest numbered mpls) one it encounters. Not sure why it does this.

libbluray does also have a feature where it considers a of disc properties (2 different ones, one called MainFeature first then one called Playlists) btw, I am yet to notice a disc where either is set though. A quick google suggests FPL_MainFeature is the way makemkv communicates it's main playlist guess as opposed to it being a property that anyone can read.

The obfuscation/DRM around BDs really is so annoying.

[Manni]

I doubt that the FPL_MainFeature comment is added by MakeMKV as other comments for other .pmls include specific information like the kind of bonus etc, so it must be on the disc. MakeMkv can't come up with that on its own. This isn't a flag by the way, it's a text comment.

Here are a few more titles where your libbluray algo doesn't pick the one selected by JRiver, in case you have one or more of these and want to double check (all UK UHD Bluray):

Ghostbusters II
Ghostbusters 2016
Gladiator
Guardian of the Galaxy 2 [edit: mistake, wasn't measured yet as sorted under "Marvel"]
Halloween 2018
Inferno
Jigsaw
Logan Lucky
The Mechanic [edit: mistake, wasn't measured yet]

That's out of around 100 titles, as measurements are still going on.

So if we add The Spy Who Dumped Me, that's a failure rate of around 10% [edit: 7%], which isn't too bad but it would be great if it could be improved.

Playlist obfuscation on bluray is annoying but AnyDVDHD ressolves this if you read disc.inf (which contains the valid track names) as JRiver does. That's one of the reasons why I use it to rip my discs, as quite a few players make use of this info when present.

[Hendrik]

FPL_MainFeature is definitely something MakeMKV invents. Discs do not contain such information. The only text information on BD discs is in BDMV\META\DL\bdmt_eng.xml, and that information is very limited.

[Manni]

FPL_MainFeature is definitely something MakeMKV invents. Discs do not contain such information. The only text information on BD discs is in BDMV\META\DL\bdmt_eng.xml, and that information is very limited.
It also only does this if you point  MakeMKV at a java installation to use, as it tries to execute BD-J to get that information, I believe.

Sorry but I don't buy this. This comment is the same information (comment in description) that gives far too precise information to be made up by makemkv.

See the screenshot attached for that title. I selected the main feature playlist, and it clearly says comment = FPL_MainFeature.

How would makemkv know that the first title is a making of, or that the fifth title are outtakes?

Doesn't make sense, so these comments in the description have to be on the disc, if not in visible text they are encrypted somewhere. I guess we'd have to ask Mike to be sure. Do you want me to or can you get in touch with him directly?

[Manni]

Another piece of data for 3lle3d00d, in Ghostbusters II both MPC-BE and makemkv detect 00003.mpls as the main title.

However, JRiver detects another one, I suspect 00001.mpls (I haven't measured it yet).

For some reason makemkv doesn't retain 00001.mpls and 00002.mpls because they have the same length as 00003.mpls. MPC-BE and your libbluray algo must be doing the same thing.

[Hendrik]

That information is something MakeMKV "guesses" by trying to run the BD-J stuff on the disc and extracting information from it. Believe me or don't, thats where it comes from. If you put enough effort into trying to interogate the BD-J menus, you can come up with some pretty good guesses. But its not quite simply some text field in some file you can read.
Try removing your Java, and that information magically disappears.

I have written Blu-ray Menu support for Media Center, I know what information is on the disc, and what is not.

[mattkhan]

How does jriver use disc.inf exactly?

[Hendrik]

It'll check if it contains a "playlists=" entry, and then favor those playlists listed there. AnyDVD only fills that entry if it detects obfuscation, however.

[mattkhan]

It'll check if it contains a "playlists=" entry, and then favor those playlists listed there. AnyDVD only fills that entry if it detects obfuscation, however.

thanks for the info

I looked at hacksaw ridge as an example, it has

playlists=977, 637

MC picks 637
977 is not visible in the MC title list and appears to be a dupe of 637 (same tracks, chapters, durations etc)

does it mean that MC works like this?

if disc.inf has playlists field, read playlists from it
if disc.inf does not (or does not exist), build list of playlists from BD

sort playlists by duration
limit list to top 10%
sort by no of audio streams
main title is the top of the list

[Manni]

That information is something MakeMKV "guesses" by trying to run the BD-J stuff on the disc and extracting information from it. Believe me or don't, thats where it comes from. If you put enough effort into trying to interogate the BD-J menus, you can come up with some pretty good guesses. But its not quite simply some text field in some file you can read.
Try removing your Java, and that information magically disappears.

I have written Blu-ray Menu support for Media Center, I know what information is on the disc, and what is not.

That information is something MakeMKV "guesses" by trying to run the BD-J stuff on the disc and extracting information from it. Believe me or don't, thats where it comes from.

I 100% trust you now that you provide an explanation that makes sense

I don't care how makemkv gets this information from, but it is clearly, as I said, from the disc. It doesn't simply make it up based on length, etc as you initially stated, because there are other tracks which are the same length, that are discarded while this track with this comment is retained, and I don't think it's by chance. Also the comments on the other tracks are accurate too.

The only thing I can tell you is that this FPV_MainFeature comment is present on quite a few titles, and accessing this comment is clearly useful in selecting the main title when there are many tracks with the same length and the same number of chapters.

In the case of The Spy Who Dumped Me, JRiver (and makemkv) selects the correct playlist anyway, but 3lled00d's tool (and MPC-BE) don't. So I was mainly providing the info to 3ll3d00d so that he can try to improve his libbluray algo and select the track that JRiver selects more often.

Ghostbuster 2016 provides an interesting example.

In that case, the main playlist identified by libbluray (in 3ll3d00d's tool) and MPC-BE is 00001.mpls, and based on the information (playlist name, Immersive HD Audio present, number of chapters) it's likely to be the correct one.

However, JRiver selects another track, and until you add the ability to display the .mpls track name I won't be able to find which one because there are too many options. Here are the tracks discarded by makemkv because they have the same length as 00001.mpls:

File 00001.mpls was added as title #0
File 00102.mpls was added as title #1
Title 00506.mpls(1) is equal to title 00001.mpls and was skipped
Title 00506.mpls(2) is equal to title 00001.mpls and was skipped
Title 00507.mpls(4) is equal to title 00001.mpls and was skipped
Title 00508.mpls(4) is equal to title 00001.mpls and was skipped
Title 00509.mpls(4) is equal to title 00001.mpls and was skipped
Title 00510.mpls(1) is equal to title 00001.mpls and was skipped
Title 00510.mpls(2) is equal to title 00001.mpls and was skipped
Title 00511.mpls(4) is equal to title 00001.mpls and was skipped
Title 00512.mpls(4) is equal to title 00001.mpls and was skipped
Title 00513.mpls(4) is equal to title 00001.mpls and was skipped
Title 00514.mpls is equal to title 00001.mpls and was skipped
Title 00515.mpls is equal to title 00001.mpls and was skipped
Title 00001.m2ts is equal to title 00001.mpls and was skipped


In that case, provided that 00001.mpls is correct as I suspect it is, then JRiver might have guessed it wrong.

[Manni]

OK, here is another example where JRiver possibly gets it wrong, and that's one where it doesn't select the track commented as "FPL_Main_Feature".

In Halloween 2018, MPC-BE and 3ll3d00d's tools detect (correctly) 00800.mpls as the main playlist.

JRiver probably selects 00801.mpls, which has the same length as 00800.mpls and is skipped by makemkv. [I've measured it and can confirm it's the one used by JRiver].

00801.mpls also has chapters, HDR and DTS:X audio, so it's not "incorrect" per se, but it would be interesting to find out why JRiver selects it over 00800.mpls.

I wonder it it would also have the "FPL_Main_Feature" attached to it or if the comment for that playlist would be different.

[Manni]

Inferno is another example similar to the Halloween 2018.

3ll3d00d's tools, MPC-BE and makemkv (correctly) identify the main playlist as 00001.mpls.

JRiver most probably selects one of the 0050x.mpls files that are discarded by makemkv, can't know which one until we can display track name.

File 00001.mpls was added as title #0
File 00102.mpls was added as title #1
Title 00506.mpls is equal to title 00001.mpls and was skipped
Title 00507.mpls is equal to title 00001.mpls and was skipped
Title 00508.mpls(2) is equal to title 00001.mpls and was skipped
Title 00508.mpls(3) is equal to title 00001.mpls and was skipped
Title 00509.mpls(2) is equal to title 00001.mpls and was skipped
Title 00509.mpls(3) is equal to title 00001.mpls and was skipped
Title 00510.mpls(4) is equal to title 00001.mpls and was skipped
Title 00511.mpls(4) is equal to title 00001.mpls and was skipped
Title 00512.mpls(2) is equal to title 00001.mpls and was skipped
Title 00512.mpls(3) is equal to title 00001.mpls and was skipped
Title 00513.mpls(2) is equal to title 00001.mpls and was skipped
Title 00513.mpls(3) is equal to title 00001.mpls and was skipped
Title 00514.mpls(4) is equal to title 00001.mpls and was skipped
Title 00515.mpls(4) is equal to title 00001.mpls and was skipped
Title 00001.m2ts is equal to title 00001.mpls and was skipped

I'm measuring the 00801.mpls in Halloween 2018, as that's most probably the one used by JRiver. I'll confirm later. [EDIT: confirmed, that's the one]

[Manni]

One last example, where I think JRiver might got it wrong.
In Jigsaw, the two obvious candidate for a main playlist are 00800.mpls (discarded by makemkv) and 00799.mpls (with the FPV_Main_Feature comment) selected as main playlist by Makemkv.

MPC-BE selects 00800.mpls, which is the same length as 00800.mpls (01:31:56).

JRiver most likely selects a third file, 00599.mpls, which I haven't measured yet but seems like the only alternative option. It's slightly shorter at 01:31:54, but it has the same number of chapters and it also contains the Atmos track, so not an "incorrect" choice per se. But interestingly, it's not commente as "FPV_Main_Feature".

Any reason why JRiver seems to give more weight to these 005xx.mpls files?

I'm not sure either of you finds this information useful, so unless you confirm it can help select improve the algos to select the correct playlist I won't post more.

EDIT: confirmed that 00801.mpls is the mpls selected by JRiver for Halloween 2018]

[Hendrik]

I'm not particularly interested in matching the results 1:1 with other applications, as long as the playlist being selected results in proper playback.

I did check Ghostbusters 2016 though and it selects 00001.mpls for me in MC. But I seem to have a slightly different version, since my MakeMKV report mentions less 005xx files being skipped (although still a bunch).
If there is identical playlists, it should always prefer the one with the lowest number.

[Manni]

I'm not particularly interested in matching the results 1:1 with other applications, as long as the playlist being selected results in proper playback.

I did check Ghostbusters 2016 though and it selects 00001.mpls for me in MC. But I seem to have a slightly different version, since my MakeMKV report mentions less 005xx files being skipped (although still a bunch).
If there is identical playlists, it should always prefer the one with the lowest number.

Fair enough, I guess you’re not using measurements files with BD Folders

Not sure why it doesn’t select the lowest number in quite a few case.

I won’t post more feedback for 3ll3d00d unless he confirms it’s useful to try to match JRiver’s selection more often.

[Hendrik]

Fair enough, I guess you’re not using measurements files

To be accurate, I don't rip discs to structures, because I think its wasteful and annoying. I just make MKVs out of them and call it a day.
But even If i were to do that, I only use one player to play HDR content - MC obviously, so not caring what others do is easy. And I've already said that we'll expose the playlist choice somewhere.

[Manni]

To be accurate, I don't rip discs to structures, because I think its wasteful and annoying.
But even If i were to do that, I only use one player to play HDR content - MC obviously, so not caring what others do is easy.

The problem is not to match other players, it’s to find a way to consistently get the same playlist results as JRiver when measuring BD Folders. At the moment JRiver’s selection doesn’t follow libbluray’s algo in Matt’s tool, so it causes issues to play the main title with measurements in JRiver. That’s the only reason why I provided other examples.

The main reason why I’m moving to JRiver is to be able to use BD Menus on some titles (especially titles with more than one version, TV series etc) as well as accessing bonuses (which are not a waste if you have a use for them). Also AFAIK BD Folders are needed to retain Dolby Vision information. Otherwise I’d still be using mkvs and MPC-BE with mymovies... I agree mkvs are more straightforward, but it’s more wasteful if you need bd folders AND mkvs

[Hendrik]

As a final note, you can already check today which playlist MC chooses by right-clicking the video and looking at the "Titles" menu. It'll offer a choice between all playlists, with the one it deems the "main" at the top.
Or you can just switch to another one there, if required to match some external factors. MC will remember your choice in its database for your next play as well.

A more automation-friendly way so you can read it via COM or MCWS or whathaveyou will be added in the future.