MakeMKV from folder and Volume Keys

[taylorwmj]

So I've been racking my head for about 2 months with this and can't figure it out:

I have a an Asustor AS5008T NAS that allows me to share USB connected devices across the network. I currently have my external LG Blu-ray drive connected to the Asustor. From my Mac's finder, I can very easily access the drive over the network. The key here is it doesn't appear as an optical drive, but rather as a directory.

This is where MakeMKV doesn't seem to want to play nice. I'm looking to simply open the folder and have MakeMKV create the MKV file but every single time it errors out when I select the BDMV package. FWIW, because Mac OS makes BDMV appear as a package, I can't open the index.bdmv in MakeMKV.

I have already placed the keydb.cfg file from labdv's site in the MakeMKV Data Directory which is set in preferences (both in that directory and then also tried in an aacs directory). Additionally, I have tried with the file in both forms of each key containing 0x and not containing it.

Every single time I receive and error telling me the volume key is unknown for this disc...and I have tried multiple blu rays contained within the keydb file.

Also, with the blu ray drive connected directly to my Mac, I can very easily rip discs. Granted, this occurs because MakeMKV is seeing it as an optical drive.

Does anyone know how I can make this work? I have attached my debug log.

001005:0000 MakeMKV v1.9.2 darwin(x86-release) started
001004:0000 Debug logging enabled, log will be saved as /Users/taylor/MakeMKV_log.txt
005042:0000 The program can't find any usable optical drives.
003006:0000 Opening files on harddrive at /Volumes/OpticalDrive
003303:0000 The volume key is unknown for this disc - video can't be decrypted
001003:0020 DEBUG: Code 0 at s5@l*F~/#rx03KN^:213131801
001003:0020 DEBUG: Code 0 at s5@l*F~/#rx03KN^:213133894
005010:0000 Failed to open disc

[Woodstock]

Networked BD ripping isn't going to work, because the network won't pass the commands to allow MakeMKV to talk directly to the drive. When it can't talk directly to the drive, it can't find the information necessary to decrypt the disk.

[taylorwmj]

Networked BD ripping isn't going to work, because the network won't pass the commands to allow MakeMKV to talk directly to the drive. When it can't talk directly to the drive, it can't find the information necessary to decrypt the disk.

While I understand what you're saying, I'm having a tough time logically applying it to the MakeMKV workflow.

If the the drive is being shared across the network with the same structure as it appears as it's connected locally, then how would doing what I'm attempting to do be any different than copying a disc completely to my computer (not as an ISO, but just as a folder) as a decrypted folder backup and then using MakeMKV to decrypt that folder to create the MKV? Whether I connect the drive locally or view it as shared over the network, I still see the same root level and files on the disc.

Also, not to give any other program PR here, (let's just say it rhymes with CavNube), but said program can open the disc just fine from a folder structure over the network as if it's local. I just prefer MakeMKV and it's stability MUCH more.

More or less, all I'm wanting to know is how to open a backup folder of a disc that's still encrypted through MKV to create an MKC and how to pass the volume keys to make. There's no clear walkthrough out there that isn't outdated and I really don't know all the files I need and where to open a decrypted folder in MakeMKV.

[Woodstock]

If we weren't talking about hardware-enforced encryption, what you say would probably be true. However, Bluray drives will not allow access to an AACS-protected disk without an exchange of a valid key. The software talking to the drive supplies that key. If the key that device has is on the lockout list of ANY disk that's been processed through the drive, it will refuse access to protected content.

In this case, the software talking directly to the drive is the NAS, not MakeMKV. And the operating system, as part of abstracting the network share to a "virtual device", inserts its own layer... So MakeMKV won't get all the information necessary for decoding things.

[taylorwmj]

MakeMKV won't get all the information necessary for decoding things.

I find this interesting because ByteCopy has no problem opening a file (and getting all info from the drive to decrypt) and I just created an MKV file this evening over the network. Then I created the file again locally using ByteCopy with the drive connected via USB to my mac. Ran a checksum and the files checked out identical.

So using your logic, why would ByteCopy talk to the drive no problem, but MakeMKV can't?

I get they're 2 different applications, but still doesn't make a whole lot of sense.

[Woodstock]

Interesting question. And there is probably something more to this "virtual drive" emulation than you have described. Does ByteCopy advertise compatibility with the drivers?

One thing I missed from your original messages is this line:

I have already placed the keydb.cfg file from labdv's site in the MakeMKV Data Directory which is set in preferences (both in that directory and then also tried in an aacs directory). Additionally, I have tried with the file in both forms of each key containing 0x and not containing it.

What is this keydb.cfg file supposed to do? A search on Google shows that it is used by some third-party libraries to provide AACS keys. Is it supposed to be a "magic bullet" to make everything that talks to BDs work?

There is no such file in MakeMKV, because it appears to use its own BD libraries. As such, it would not be read; MakeMKV is self-contained. In fact, there are provisions in MakeMKV to replace the libraries that use keydb.cfg, so that you won't be dependent upon that.

MakeMKV reads the disk to get the information needed to decode. Applications that are dependent upon something like keydb.cfg are using a database generated by something else. If reading the USB drive across the net is going to require an application that uses keydb.cfg, then MakeMKV probably isn't it.

Maybe Mike will see this and tell me I'm off-base, but I don't see it working without changing MakeMKV from "stand alone" to "dependent upon third parties".