www.makemkv.com

I assume the current userbase for MakeMKV on ARM64 is pretty small but I hope the following bug can still be fixed since recent changelogs also show ARM fixes.

For some reason (other people also confirmed it) UHD Blu-ray’s always error out in the beginning and want you to submit the dump for keys. Under Windows X86 the same Disc works just fine.

I also tried manually supplying a keydb.cfg but it still couldn’t decrypt.

mtotheb wrote: ↑

Thu Mar 28, 2024 6:28 pm

I assume the current userbase for MakeMKV on ARM64 is pretty small but I hope the following bug can still be fixed since recent changelogs also show ARM fixes.

For some reason (other people also confirmed it) UHD Blu-ray’s always error out in the beginning and want you tophrazle submit the dump for keys. Under Windows X86 the same Disc works just fine.

I also tried manually supplying a keydb.cfg but it still couldn’t decrypt.

I edited three registry files: one to enable the batch script to be played via VLC's Autoplay of DVDs and Blu-rays, one to disable the commandeer function, and one to generate backup Autoplay listings specifically for DVDs and Blu-rays. As this is my first batch script in a while, I would appreciate any suggestions for enhancement.

ineafowlahead wrote: ↑

Mon May 06, 2024 3:55 am

I edited three registry files: one to enable the batch script to be played via VLC's Autoplay of DVDs and Blu-rays, one to disable the commandeer function, and one to generate backup Autoplay listings specifically for DVDs and Blu-rays. As this is my first batch script in a while, I would appreciate any suggestions for enhancement.

What does this have to do with Arm64 linux?

I think I replied to a spam/copy-pasta thread at viewtopic.php?f=1&t=34275

mtotheb wrote: ↑

Thu Mar 28, 2024 6:28 pm

I also tried manually supplying a keydb.cfg but it still couldn’t decrypt.

I double-checked, but make sure you name it KEYDB.cfg (case-sensitive on Linux) or it won't be found.

segfaulted wrote: ↑

Fri Jun 14, 2024 4:39 pm

I think I replied to a spam/copy-pasta thread at viewtopic.php?f=1&t=34275

That is so weird it seems to be a spam/copy of my account??

I double-checked, but make sure you name it KEYDB.cfg (case-sensitive on Linux) or it won't be found.

Was your success in the other thread without or with manually supplied KEYDB.cfg. Also super cool that you also did this with a Rockchip SBC. At first I was like no way this could work but then I asked myself why not and that’s how I ended up with this situation.

mtotheb wrote: ↑

Fri Jun 14, 2024 9:41 pm

Was your success in the other thread without or with manually supplied KEYDB.cfg. Also super cool that you also did this with a Rockchip SBC. At first I was like no way this could work but then I asked myself why not and that’s how I ended up with this situation.

It was done without the keydb.cfg file, only using MakeMKV's regular HK update to fetch the keys.

I tried 2x 4K BluRays and it still does not work on Arm.
Normal BluRays work just fine

mtotheb wrote: ↑

Fri Jul 19, 2024 9:08 pm

I tried 2x 4K BluRays and it still does not work on Arm.
Normal BluRays work just fine

"The program can't find any usable optical drives" is the main problem here. MakeMKV needs direct access to the UHD drive to read encrypted 4K discs. Browsing to a mounted directory won't work.

Does your user account have permissions to handle your bluray drive's block device, probably /dev/sg0 or some other sg device?
And where did you install MakeMKV from (flatpak, snap, or compiled from source)? Some of those runtimes could sandbox MakeMKV by default, so it won't be able to reach the block devices as intended.

segfaulted wrote: ↑

Sat Jul 20, 2024 5:26 am

"The program can't find any usable optical drives" is the main problem here. MakeMKV needs direct access to the UHD drive to read encrypted 4K discs. Browsing to a mounted directory won't work.

That’s the first time I‘ve heard that. I mean I can try again with the BluRay Drive connected to the ARM device.. didn’t think it would make a difference. The directory in this case was just a undecrypted backup from a windows pc running MakeMKV to test.

When I first tried it though I also had the drive connected directly. I'm using jlesage/makemkv docker image. Maybe you try and can see if that is the issue?

mtotheb wrote: ↑

Sat Jul 20, 2024 3:42 pm

I'm using jlesage/makemkv docker image. Maybe you try and can see if that is the issue?

Alright, I tried out that docker image. I noticed the example command from the readme to run the container uses /dev/sg2 which you need to adjust to refer to your bluray drive's sg* device. If your ARM system has no other scsi/sata devices plugged in, the bluray drive should be on /dev/sg0 as it was on mine.

Use a tool such as lsscsi -g or sg_map to locate the correct sg device. The readme also talks about including /dev/sr0 in the docker run command, though that was not necessary in my experience.

After that's been set up correctly, ripping 4K discs worked with that docker image.

-------

I also tested using encrypted rips from another machine, which is what you're trying to do. MakeMKV can load the rip if the correct HK database is already downloaded. In other words, the appropriate MKB20_v??_save.tgz needs to be stashed in _private_data.tar or placed in MakeMKV's data directory. The ?? corresponds to the disc's MKB version, so 77 would be it for your rip of Barbie 4K. If your Windows machine had no issues opening the rip, you should be able to copy your _private_data.tar to the Linux install and have it work there.

Loading a disc or iso file will sometimes trigger the HK update for the disc's v?? database, but loading a directory does not update it.

There is also KEYDB.cfg which can also successfully open an encrypted rip when the title is in that database.