Should I email dump if makemkv can decrypt disc with keydb.cfg from FindVUK?

[tomty89]

Hi all. So I'm new to UHD ripping so this might be an asked / silly question. So I couldn't decrypt a disc and got the volume key unknown error. I think it could be just that I'm geoblocked from host of the HK file.

However, after I downloaded keydb.cfg from http://fvonline-db.bplaced.net/ and place it under the ~/.MakeMKV, decryption seems to be working fine. (I'm still ripping it.) Does that mean I should not bother anyone with the tgz dump?

P.S. I think it is using "processing key" instead of a "volume unique key" from the keydb.cfg for the disc, if that makes a difference in what I should do.

---

Also, is it possible that I would bump into a disc that can't be decrypted using keydb.cfg from FindVUK but can be using HK file (that I couldn't obtain)? (I mean, will they be "synchronized" with each other from time to time?) In other words should I try to bypass the geoblock in any case? (And does AACS 2.1 / FMTS makes a difference with this regard?)

[MartyMcNuts]

Hi all. So I'm new to UHD ripping so this might be an asked / silly question. So I couldn't decrypt a disc and got the volume key unknown error. I think it could be just that I'm geoblocked from host of the HK file.

However, after I downloaded keydb.cfg from http://fvonline-db.bplaced.net/ and place it under the ~/.MakeMKV, decryption seems to be working fine. (I'm still ripping it.) Does that mean I should not bother anyone with the tgz dump?

P.S. I think it is using "processing key" instead of a "volume unique key" from the keydb.cfg for the disc, if that makes a difference in what I should do.

---

Also, is it possible that I would bump into a disc that can't be decrypted using keydb.cfg from FindVUK but can be using HK file (that I couldn't obtain)? (I mean, will they be "synchronized" with each other from time to time?) In other words should I try to bypass the geoblock in any case? (And does AACS 2.1 / FMTS makes a difference with this regard?)

Yes, you should fix your geo-blocking issue if you have one. The log would say something about HK download disabled if that is the case.

No, MakeMKV's internal HK database and the KeyDB do not sync with each other. They are 2 totally separate databases.

No, MakeMKV uses volume keys to rip discs no matter if it comes from KeyDB or it's internal HK.

Yes, once you have fixed your ge-blocking issue if you have one and do come across a disc that the volume key is not know, you definetly should email in the dump to svq@makemkv.com so it a hashed key can be generated and added to MakeMKV's HK database.

[keydb_helper]

Does that mean I should not bother anyone with the tgz dump?

The MakeMKV team have been nice enough to allow the keydb submission thread to exist. I'm sure it would push the limits of their hospitality if users began neglecting MakeMKV's native title support in favour of the public keydb.

So the advice from everyone who contributes to the public keydb has always been to continue emailing disc dump files for unsupported discs to the MakeMKV team.

P.S. I think it is using "processing key" instead of a "volume unique key" from the keydb.cfg for the disc, if that makes a difference in what I should do.

There are no AACS 2.0 processing or device keys in the public keydb. If your disc was UHD/AACS 2.0, MakeMKV utilised the VUK for your disc.

Also, is it possible that I would bump into a disc that can't be decrypted using keydb.cfg from FindVUK but can be using HK file (that I couldn't obtain)?

Yes, that is absolutely a possibility. There are many titles which are supported by one database and not the other.

I mean, will they be "synchronized" with each other from time to time?

No. The public keydb does not utilise keys from MakeMKV and there is no indication that MakeMKV is using keys from the public keydb.

The two key sources effectively exist like Spotify and Apple Music: there is significant overlap and some time-limited exclusives, but no coordinated syncing of content.

And does AACS 2.1 / FMTS makes a difference with this regard?

The public keydb doesn't fully support AACS 2.1. Even if the public keydb did eventually support AACS 2.1, I don't believe MakeMKV would utilise this support.

[MrPenguin]

And does AACS 2.1 / FMTS makes a difference with this regard?

The public keydb doesn't fully support AACS 2.1. Even if the public keydb did eventually support AACS 2.1, I don't believe MakeMKV would utilise this support.

To be fair, I believe there are only 5 different titles using AACS v2.1. And some of these have recently been re-released using AACS v2.0 anyway.

Theoretically, while there are also some experimental patches for libaacs/libbluray that would allow AACSv2.1 playback, there isn't a corresponding set of extra keys for all these AACSv2.1 disks that would allow people to use them . Nor is this position likely to change any time soon either.