Dump Submitted Longlegs UHD

[bsather]

MKB20_v77_UHD_LNGL_5A36

[MrPenguin]

MKB20_v77_UHD_LNGL_5A36

The latest KEYDB.cfg file contains this entry:

Code: Select all

0xE7CBD3E945FA4C761B95A1034BF8F2A4C5935806 = UHD_LNGL (Longlegs) | D | 2024-06-29

Does copying this file into MakeMKV's data directory (i.e. where MakeMKV also writes its TGZ dump files) and restarting MakeMKV help?

[bsather]

Yes. Thank you!

[astrocoolin]

submitted

Code: Select all

MKB20_v77_Longlegs_2294

[keydb_helper]

submitted

Code: Select all

MKB20_v77_Longlegs_2294

The 2294 release of Longlegs with the disc ID 0xD30AD1993F62659F39FE355405295DE1C0EDFC5D has been added to the public keydb. It should work with your disc.

[Ballesteros]

Submitted MKB20_v77_Longlegs_8AD0.tgz for UK UHD release.

[sandersoni]

Submitted MKB20_v77_Longlegs_8AD0.tgz for UK UHD release.

Thank you!

[sandersoni]

MKB20_v77_UHD_LNGL_5A36

The latest KEYDB.cfg file contains this entry:

Code: Select all

0xE7CBD3E945FA4C761B95A1034BF8F2A4C5935806 = UHD_LNGL (Longlegs) | D | 2024-06-29

Does copying this file into MakeMKV's data directory (i.e. where MakeMKV also writes its TGZ dump files) and restarting MakeMKV help?

In since this morning.

[lexwalk]

Submitted MKB20_v77_Longlegs_B818.tgz

I just emailed is that log dump to svq, did I need to do anything else?

[MrPenguin]

Submitted MKB20_v77_Longlegs_B818.tgz

I just emailed is that log dump to svq, did I need to do anything else?

No, but it would be "kind" to KEYDB if you could also make your TGZ dump available somehow please, e.g. attach it to a reply here or post a link to (say) Google Drive or OneDrive?

Have you tried downloading the latest KEYDB.cfg file, copying it into MakeMKV's data directory (i.e. where MakeMKV also writes TGZ dump files) and restarting MakeMKV?

[lexwalk]

Submitted MKB20_v77_Longlegs_B818.tgz

I just emailed is that log dump to svq, did I need to do anything else?

No, but it would be "kind" to KEYDB if you could also make your TGZ dump available somehow please, e.g. attach it to a reply here or post a link to (say) Google Drive or OneDrive?

Have you tried downloading the latest KEYDB.cfg file, copying it into MakeMKV's data directory (i.e. where MakeMKV also writes TGZ dump files) and restarting MakeMKV?

Downloaded that file and placed it in the MakeMKV data folder (unzipped and zipped) and when I restarted MakeMKV and tried to re-open the Longlegs 4K disc it still produced the dump file attached here. However there's no indication MakeMKV tried to consume the new keydb.cfg upon opening (no text saying it's doing so in the log when launching or opening the disc). Do I need to rename it? It's sitting in the same place where it writes dump files. How will I know if it's been properly consumed?

MakeMKV v1.17.9 win(x64-release) started
Using LibreDrive mode (v06.3 id=4C194CE2C4D1)
Using direct disc access mode
Loaded content hash table, will verify integrity of M2TS files.
Saved AACS dump file as C:\Users\------/.MakeMKV/MKB20_v77_Longlegs_B818.tgz
The volume key is unknown for this disc - video can't be decrypted
Failed to open disc

Here is the link for the dump file...
https://drive.google.com/file/d/15y-MWY ... sp=sharing

[keydb_helper]

Downloaded that file and placed it in the MakeMKV data folder (unzipped and zipped) and when I restarted MakeMKV and tried to re-open the Longlegs 4K disc it still produced the dump file attached here. However there's no indication MakeMKV tried to consume the new keydb.cfg upon opening (no text saying it's doing so in the log when launching or opening the disc). Do I need to rename it? It's sitting in the same place where it writes dump files. How will I know if it's been properly consumed?

I might be mistaken but I don't believe MakeMKV provides any indication in its logs when it is using the public keydb. In your case we know that MakeMKV couldn't utilise the keydb because there was no key for your disc in the public keydb at that time.

If you have the extracted "keydb.cfg" file in the same directory where your dump files are created then you have followed the correct process.

To check if your disc is supported, you can calculate the SHA-1 hash of the "Unit_Key_RO.inf" file in your discs "AACS" folder. If there is a matching entry in the keydb.cfg file you have a good chance of being able to decrypt your disc.

Here is the link for the dump file...
https://drive.google.com/file/d/15y-MWY ... sp=sharing

Thanks for providing the dump file. Your variant of Longlegs has now been added to the public keydb. So download the latest keydb file and replace your local copy or use SamuriHL's keydb utility for Windows (Link)

[lexwalk]

Downloaded that file and placed it in the MakeMKV data folder (unzipped and zipped) and when I restarted MakeMKV and tried to re-open the Longlegs 4K disc it still produced the dump file attached here. However there's no indication MakeMKV tried to consume the new keydb.cfg upon opening (no text saying it's doing so in the log when launching or opening the disc). Do I need to rename it? It's sitting in the same place where it writes dump files. How will I know if it's been properly consumed?

I might be mistaken but I don't believe MakeMKV provides any indication in its logs when it is using the public keydb. In your case we know that MakeMKV couldn't utilise the keydb because there was no key for your disc in the public keydb at that time.

If you have the extracted "keydb.cfg" file in the same directory where your dump files are created then you have followed the correct process.

To check if your disc is supported, you can calculate the SHA-1 hash of the "Unit_Key_RO.inf" file in your discs "AACS" folder. If there is a matching entry in the keydb.cfg file you have a good chance of being able to decrypt your disc.

Here is the link for the dump file...
https://drive.google.com/file/d/15y-MWY ... sp=sharing

Thanks for providing the dump file. Your variant of Longlegs has now been added to the public keydb. So download the latest keydb file and replace your local copy or use SamuriHL's keydb utility for Windows (Link)

Just providing an update. Thank you all, with the updated keydb.cfg from today in my data folder, my disc was now able to be read. Thank you all for your help, this was an educational experience and I'll make sure to follow these steps next time I encounter this.