The volume key is unknown for this disc

[MartyMcNuts]

I was successful today at ripping Wonka (2023) 4K

It did show "Downloading latest HK..." this time

Here is the log:

MakeMKV v1.17.6 win(x64-release) started
Debug logging enabled, log will be saved as C:\Users\[USERNAME]/MakeMKV_log.txt
Using LibreDrive mode (v06.3 id=4083C4CCDB14)
Using direct disc access mode
Loaded content hash table, will verify integrity of M2TS files.
Downloading latest HK to C:\Users\taftb/.MakeMKV ...

So if the other discs still don't work, submit the dumps (send them in separate emails to svq@makemkv.com) as they may be from a new batch of discs.

[MyJunkIsBroken]

So if the other discs still don't work, submit the dumps (send them in separate emails to svq@makemkv.com) as they may be from a new batch of discs.

Hmm... I did send them as a single email both times I submitted them. Maybe I missed the guidance to keep them separate? Either way, two fresh emails sent.

Thanks.

[MyJunkIsBroken]

I submitted them for the third time 9 days ago, and I still am getting this:

Code: Select all

MakeMKV v1.17.6 win(x64-release) started
Debug logging enabled, log will be saved as C:\Users\owner/MakeMKV_log.txt
DEBUG: Code 0 at WKYQi`r2nRn]/W8S:213144750
Using LibreDrive mode (v06.3 id=4C194CE2C4D1)
Using direct disc access mode
Loaded content hash table, will verify integrity of M2TS files.
DEBUG: Code 0 at WKYQi`r2nRn]/W8S:29399956
Saved AACS dump file as D:/Video/MKB20_v60_The_Martian_-_Extended_Edition_F8C9.tgz
The volume key is unknown for this disc - video can't be decrypted
DEBUG: Code 0 at g1G,9/u[_c:!rg}]:213132721
DEBUG: Code 0 at g1G,9/u[_c:!rg}]:213131341
Failed to open disc

I have no idea if the disc has been added to the online db. I have updated my local database with findvuk synchronize. Am I correct in assuming that is a different resource than MakeMKV uses with internet access? I've tried internet access enabled, with and without several different vpns. I'm kind of at a loss here since the MakeMKV log never states that it is trying to get the volume key.

Without a vpn, I don't see any dns entries in pi-hole. With a vpn, I do see a connection and traffic to the vpn server on opnsense firewall.

Any suggestions on diagnosing this?

[dcoke22]

I have no idea if the disc has been added to the online db. I have updated my local database with findvuk synchronize. Am I correct in assuming that is a different resource than MakeMKV uses with internet access?

Yes, that's a different thing than MakeMKV downloading its own hashed keys with internet access enabled.

[dcoke22]

I submitted them for the third time 9 days ago, and I still am getting this:

Code: Select all

MakeMKV v1.17.6 win(x64-release) started
Debug logging enabled, log will be saved as C:\Users\owner/MakeMKV_log.txt
DEBUG: Code 0 at WKYQi`r2nRn]/W8S:213144750
Using LibreDrive mode (v06.3 id=4C194CE2C4D1)
Using direct disc access mode
Loaded content hash table, will verify integrity of M2TS files.
DEBUG: Code 0 at WKYQi`r2nRn]/W8S:29399956
Saved AACS dump file as D:/Video/MKB20_v60_The_Martian_-_Extended_Edition_F8C9.tgz
The volume key is unknown for this disc - video can't be decrypted
DEBUG: Code 0 at g1G,9/u[_c:!rg}]:213132721
DEBUG: Code 0 at g1G,9/u[_c:!rg}]:213131341
Failed to open disc

When you test for updated hashed keys, are you putting the UHD disc in your BP60NB10? I seem to recall MakeMKV often has a line or two about the optical drives near the top of the log and I don't see that in your log. For example:

Code: Select all

MakeMKV v1.17.4 darwin(arm64-release) started
Optical drive "BD-RE ASUS BW-16D1HT 3.10 KLUJ5MD3517d" opened in OS access mode.
Using LibreDrive mode (v06.3 id=0FA242DD4D0B)
Using direct disc access mode
Loaded content hash table, will verify integrity of M2TS files.
Saved AACS dump file as ***/Library/MakeMKV/MKB20_v77_John_Wick-_Chapter_4_51AE.tgz
The volume key is unknown for this disc - video can't be decrypted
Failed to open disc

(that log stolen from this post)

I'm just speculating why your installation of MakeMKV might not be attempting to look up new hashed keys. Have you attempted to rip any UHDs since The Martian or Bohemian Rhapsody? If you read the explanation at the hashed keys link from my earlier post, you should be able to find the file where MakeMKV stores the downloaded hashed keys. As a test, if you move that file out of its home, start MakeMKV, insert any UHD, MakeMKV should try to download the latest version of the hashed keys.

[smartieyoung]

I have been away from forum for over a year, I thought I had forgotten my password and would you know my Chromebook did.now into my question as related to topic. I just used makemkv for the first time since this past fall when I got Oppenheimer it worked fine but I wanted to try one last night and it uncut diamonds and I saw it was having trouble getting the hashed key or volume key,funny thing is that I was still able to decrypt this disc .I assume I wouldn't have been able to open that disc without a key?

[dcoke22]

I assume I wouldn't have been able to open that disc without a key?

Yes, for 4K UHDs, that's correct.

[MyJunkIsBroken]

When you test for updated hashed keys, are you putting the UHD disc in your BP60NB10?

Thanks so much for trying to help me out with this...

Yes. My BDR-XD08U has too new of firmware to rip UHD (ID05).

I get this with that drive, as expected:

Code: Select all

{ tons of lines with scsi errors and debug codes }
Error 'Scsi error - ILLEGAL REQUEST:CANNOT WRITE MEDIUM - INCOMPATIBLE FORMAT' occurred while issuing SCSI command A40..002000800 to device 'SPTI:\Device\CdRom1'
Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' occurred while issuing SCSI command AD010..080002400 to device 'SPTI:\Device\CdRom1'
DEBUG: Code 0 at a%48&'jm4Zb*$m{*oY:121264395
DEBUG: Code 4 at a%48&'jm4Zb*$m{*oY:213130789
Can't read AACS VID from disc - most likely current AACS host certificate is revoked by your drive
Saved AACS dump file as D:/Video/MKB20_v60_The_Martian_-_Extended_Edition_F8C9.tgz
LibreDrive compatible drive is required to open this disc - video can't be decrypted.
DEBUG: Code 0 at g1G,9/u[_c:!rg}]:213132721
DEBUG: Code 0 at g1G,9/u[_c:!rg}]:213131341
Failed to open disc

I seem to recall MakeMKV often has a line or two about the optical drives near the top of the log and I don't see that in your log. For example:

Code: Select all

Optical drive "BD-RE ASUS BW-16D1HT 3.10 KLUJ5MD3517d" opened in OS access mode.

My logs do not have that line even when I have both drives hooked up, or with single access mode on or off. Maybe that is only logged in that example because of the 'OS access mode'?

I'm just speculating why your installation of MakeMKV might not be attempting to look up new hashed keys. Have you attempted to rip any UHDs since The Martian or Bohemian Rhapsody?

I'm curious if it is trying to look up keys, but is being blocked either by pi-hole, my firewall (I have some pretty strict dns rules to force all devices go through pi-hole). I also block dns over TLS and dns over HTTPS for that reason. Regardless of my setup, using a vpn would bypass that. A line in the log saying "Trying to get keys...", with a pass fail message would go a long way here.

Have you attempted to rip any UHDs since The Martian or Bohemian Rhapsody?

These are sadly the only 2 4K movies I own.

If you read the explanation at the hashed keys link from my earlier post, you should be able to find the file where MakeMKV stores the downloaded hashed keys. As a test, if you move that file out of its home, start MakeMKV, insert any UHD, MakeMKV should try to download the latest version of the hashed keys.

If you are talking about the '_private_data.tar' file, yes. I have moved and let it rebuild that. It increases in size with every disc that has a different AACS version, plain ol BDR or UHD.

[dcoke22]

I seem to recall reading on this forum that MakeMKV uses DNS over HTTPS to do lookups for hashed key server. I can't find the relevant posts because search terms of less than 4 characters are ignored on this forum (can't search for DNS) and most links start with https these days. In any case, I wonder if your firewall or pi-hole logs would show such a query?

Normally, when MakeMKV tries to download new hashed keys, there's a line in the log similar to:

Code: Select all

Downloading latest HK to C:\Users\...

If that fails, then there's the:

Code: Select all

Automatic HK downloading is disabled or failed.

If it works, then either the UHD in question decrypts or you get the "can't decrypt, saving a dump" message, which implies that the hashed key needed isn't yet available.

Regarding using a VPN… it could work via a VPN, but depending on the output node you end up on, if that network is geo-IP blocking or otherwise filtering network traffic, they might drop the response if the servers/IP it is hosted on is blacklisted. Some users have to try several output nodes until they find one that works. That said, they usually get the HK downloading failed message.


There is one thing you could try. The first post of the Ultimate UHD Drives Flashing Guide thread has way down at the bottom in the Useful Links section, a link to the set of hashed keys that were available as of April, 2022 (Thanks Billycar11). You could try putting that _private_data.tar in your setup and seeing if you can decrypt your UHDs (which came out in 2016 and 2019).

[MyJunkIsBroken]

I seem to recall reading on this forum that MakeMKV uses DNS over HTTPS to do lookups for hashed key server. I can't find the relevant posts because search terms of less than 4 characters are ignored on this forum (can't search for DNS) and most links start with https these days. In any case, I wonder if your firewall or pi-hole logs would show such a query?

Normally, when MakeMKV tries to download new hashed keys, there's a line in the log similar to:

Code: Select all

Downloading latest HK to C:\Users\...

If that fails, then there's the:

Code: Select all

Automatic HK downloading is disabled or failed.

If it works, then either the UHD in question decrypts or you get the "can't decrypt, saving a dump" message, which implies that the hashed key needed isn't yet available.

My logs definitely never say anything regarding that. I've posted exactly what it says...

Regarding using a VPN… it could work via a VPN, but depending on the output node you end up on, if that network is geo-IP blocking or otherwise filtering network traffic, they might drop the response if the servers/IP it is hosted on is blacklisted. Some users have to try several output nodes until they find one that works. That said, they usually get the HK downloading failed message.

It seems this may have been the case with the several public vpns I tried. Again, there was nothing in the logs regarding connecting, downloading, trying, failing, network, etc.

There is one thing you could try. The first post of the Ultimate UHD Drives Flashing Guide thread has way down at the bottom in the Useful Links section, a link to the set of hashed keys that were available as of April, 2022 (Thanks Billycar11). You could try putting that _private_data.tar in your setup and seeing if you can decrypt your UHDs (which came out in 2016 and 2019).

Thank you so much... This worked (at least with The Martian so far... ripping now). Clearly with my setup, MakeMKV is not able to connect to download the keys, but it never gives any logging for whatever reason. I saw there was a thread for the downloadable hashed keys, but the links seem to have been removed.

I don't expect the current process to change to fix my edge case situation, but I've seen enough other complaints about not getting keys without a vpn. Maybe there is a solution for users like me, or offline systems in general? I'll clearly have issues if I buy anything newer than is not in that _private_data.tar.

[SamuriHL]

Ultimately you want to try to find a way to fix the issues you're having with downloading keys. I only partially glanced through but make sure debug logging is enabled in the settings. It might provide more of an answer.

Additionally, one thing you can do is use the KEYDB.cfg file. See this:

viewtopic.php?p=150311#p150311

There's other information on it scattered through the forum and a modified script for use with FindVUK that coopervid provided, as well. But if there's an entry for whatever disc you're having issues with in the future, this might provide another option.

[MyJunkIsBroken]

I only partially glanced through but make sure debug logging is enabled in the settings. It might provide more of an answer.

Additionally, one thing you can do is use the KEYDB.cfg file. See this:

viewtopic.php?p=150311#p150311

There's other information on it scattered through the forum and a modified script for use with FindVUK that coopervid provided, as well. But if there's an entry for whatever disc you're having issues with in the future, this might provide another option.

Thanks for the reply.

Debug logging is enabled. I also have the FindVUK - Synchronize.bat script set up, and it also places a copy in my MakeMKV data folder. That was one of the first things I tried in hopes of resolving this.

Ultimately you want to try to find a way to fix the issues you're having with downloading keys.

I think we figured out how to fix it in my case. ...allowing DoH or DoS DNS out from my firewall. I choose to block those in order to keep an eye on all of my devices and make sure they aren't doing anything shady.
Unfortunately, there are other users who will also have issues if their ISP, College, whatever blocks those or does geo-blocking.

[SamuriHL]

Yea so many people have DNS issues and/or ISP issues. I'm blessed to be on a fiber network that couldn't care less but I also use alternative DNS for my network. I've never had a problem downloading the hashed keys. But it's a real issue for many.

[MyJunkIsBroken]

Yea so many people have DNS issues and/or ISP issues. I'm blessed to be on a fiber network that couldn't care less but I also use alternative DNS for my network. I've never had a problem downloading the hashed keys. But it's a real issue for many.

I just verified it is in fact my firewall rules. I created a rule to allow my desktop to connect to any DoH server, renamed my _private_data.tar, and here's the log:

MakeMKV v1.17.6 win(x64-release) started
Debug logging enabled, log will be saved as C:\Users\owner/MakeMKV_log.txt
Downloading latest SDF to D:/Video ... <------- this is the first time I've ever seen anything regarding downloads.
Using LibreDrive mode (v06.3 id=4C194CE2C4D1)
Using direct disc access mode
Loaded content hash table, will verify integrity of M2TS files.
Downloading latest HK to D:/Video ... <--------- this is also new.
Using Java runtime from C:/Program Files/Java/jre-1.8/bin/java.exe
{ ------------lines regarding title scanning redacted---------- }
Operation successfully completed

I have no idea why it never logs that it fails with my firewall blocking the traffic.

I just hope this helps someone in the future.

[SamuriHL]

Maybe your firewall simply ate the request and MakeMKV still thought it would at some point get a response and never logged it? Who knows. But good that you found it.