Uncut Gems

[Steveredrum]

Uncut Gems [U.S.A - Retail] = Screen Pass - 00798.MPLS

[KENSAI]

Any ideas on the Redbox US version? This is what Java reports:

Name: Uncut Gems
Comment: FPL_MainFeature
Source file name: 00893.mpls
Duration: 2:15:08
Chapters count: 16
Size: 38.9 GB
Segment count: 20
Segment map: 517,513,518,514,505,519,502,504,520,511,501,516,512,506,508,509,503,510,515,507
File name: Uncut Gems-FPL_MainFeature_t02.mkv

[PrideOfPR7]

RB US version (Procmon verified):

Title information
Name: Uncut Gems
Source file name: 00798.mpls
Duration: 2:15:08
Chapters count: 16
Size: 38.9 GB
Segment count: 20
Segment map: 517,518,513,514,505,502,519,504,520,511,501,516,512,508,509,506,503,510,515,507
File name: Uncut Gems_t318.mkv

[oldsatcat]

I used free bluray player with procmon filter set to mpls and come up with 0008

[RoyGBiv]

Any idea what the playlist for the Netflix version is?

SMK

[RoyGBiv]

Bump:

Has anyone verified the NF mpls?

SMK

[fromashestoeden]

RB US version (Procmon verified):

Title information
Name: Uncut Gems
Source file name: 00798.mpls
Duration: 2:15:08
Chapters count: 16
Size: 38.9 GB
Segment count: 20
Segment map: 517,518,513,514,505,502,519,504,520,511,501,516,512,508,509,506,503,510,515,507
File name: Uncut Gems_t318.mkv

I concur with this on Netflix US 00798. I verified it while playing the disc chapter by chapter.

517,518,513,514, 505, 502,519,504, 520,511,501,516,512,508,509,506,503,510,515,507

505 Is mostly static through all mpls. I memorized the first four 517,518,513,514 then watch for the 3 after 505 to change. then match the first four as the next three fell in order. I went through all of them in about 10 mins.

[laguna_b]

I ripped but not yet viewed 798 but there was this message on MakeMKV listing another play list: "SPBD Copy Disclaimer Playlist"

Name: Uncut Gems (English)
Comment: SPBD Copy Disclaimer Playlist
Source file name: 00448.mpls
Duration: 2:16:08
Chapters count: 17
Size: 38.9 GB
Segment count: 21
Segment map: 517,2471,503,512,511,514,502,519,509,518,501,508,510,513,506,504,516,505,515,520,507
File name: Uncut Gems-SPBD Copy Disclaimer Playlist_t00.mkv

Versus 798

Segment count: 20
Segment map: 517,518,513,514,505,502,519,504,520,511,501,516,512,508,509,506,503,510,515,507
File name: Uncut Gems_t318.mkv

Is the first one tagged by MKV or? They are obviously in different order and content. 798 seems to be the one here tagged as valid by users.
This is a Netflix copy.

[minkiz88]

798 definitely is not the correct one for the retail disc. 30 minutes in, it swaps two parts of a scene. It's almost unnoticeable, because it kind of "works" in a weird way.

[Krawk]

The program automatically chooses 893 for U.S. retail. But no replies point to this so I have my doubts. So do I trust this? 798 (above) appears to have same segment map, so are they identical?
Segment map: 517,513,518,514,505,519,502,504,520,511,501,516,512,506,508,509,503,510,515,507
File name: Uncut Gems-FPL_MainFeature_t03.mkv

[forresthopkinsa]

893 is 60 seconds shorter than 448 (2:15:08 vs 2:16:08). Interestingly, when playing the movie in VLC, the disc's custom pause menu shows a running time of 2:15:08, while VLC's duration shows 2:16:08. In fact, during the last minute of running time, the custom pause menu will show e.g. "2:15:45 / 2:15:08". Not sure what to make of this.

Here's my disc info, all the same as everyone else has posted but I thought I'd compile it in one spot:

Comment: SPBD Copy Disclaimer Playlist
Source file name: 00448.mpls
Duration: 2:16:08
Chapters count: 17
Size: 38.9 GB
Segment count: 21
Segment map: 517,2471,503,512,511,514,502,519,509,518,501,508,510,513,506,504,516,505,515,520,507
File name: Uncut Gems-SPBD Copy Disclaimer Playlist_t01.mkv

893 has a dramatically different segment map:

Comment: FPL_MainFeature
Source file name: 00893.mpls
Duration: 2:15:08
Chapters count: 16
Size: 38.9 GB
Segment count: 20
Segment map: 517,513,518,514,505,519,502,504,520,511,501,516,512,506,508,509,503,510,515,507
File name: Uncut Gems-FPL_MainFeature_t07.mkv

Here's 798 as mentioned elsewhere in this thread, notice the very subtle differences from 893:

Source file name: 00798.mpls
Duration: 2:15:08
Chapters count: 16
Size: 38.9 GB
Segment count: 20
Segment map: 517,518,513,514,505,502,519,504,520,511,501,516,512,508,509,506,503,510,515,507
File name: Uncut Gems_t320.mkv

I haven't seen this movie yet (Christmas present) so I can't speak to the segments specifically. It'd be a bummer to watch it for the first time out-of-order though.

[minkiz88]

Ripping 448 now to watch later.

Interestingly, my disc doesn't even have an 893... D: That was the one I was planning on testing next, since I'm positive it's not 798.

I'm using the regular, retail disc.

EDIT: I'm on the newest version of MakeMKV, paid. Drive is a custom flashed LG WH14NS40. All of the listed mpls are listed generically, no playlist is picked by MakeMKV. Additionally, looking through the read code, I get "Title 00893.mpls is equal to title 00686.mpls and was skipped." So I might try 686 next?

EDITx2: Wait, are the "segments" chapters in the movie? Because if that's the case I can figure it out much easier just by flipping the two scenes that were garbled in 798. Also it's definitely not 448. In addition to the Copyright Disclaimer, the scenes are all out of order.

FINAL EDIT: Sorry for adding, but I checked 686/893, not correct, either. To be specific, the scenes between 33:18-34:18 are jumbled up. Confirmed by watching the specific scene on Netflix. It's kind of obvious (her, umm... outfit changes, then changes back, then changes again in the scene), but seems like it could just be a creative way of showing it out of sequence, but it's definitely not correct.

[Krawk]

I used RedFox and it selects 798. I know Pete over there does some actual processing of the disc code when choosing the right playlist and then the OPD selects it for you.

Again, sorry, but working on 4K is great, but can we get a proper working Lionsgate fix? These guys do the same on 4K as well. How come a set top player doesn't get the wrong playlist? It processes the java code, right?