Libredrive Compatibility (UHD Disc Only)

[J-miahL]

Problem: I am unable to rip a UHD disc on Docker Image v 23.0.6.1. I continue to get a "SCSI Error-Illegal Request: Copy Protection Key Exchange Failure - Key not Present", which eventually leads to a "Can't read AACS VID from disc-most likely current AACS host certificate is revoked." The process ends with an "LibreDrive compatible drive is required" message.

Troubleshooting: the container is able to detect my drive and shows that LibreDrive is enabled. I am able to rip regular bluray disc without issue. My original drive was replaced as it failed. I have tried ripping UHD I've had success with my original drive and I get the same error. I tested my current drive on my PC and it was able to rip the UHD without issue. The last version I used to successfully rip an UHD was 1.17.3. I have tried two different drives with the same results.

Theories: Looking through the MakeMKV forum, a source of the problem can be related to permissions. The container is not running in privilege mode. I also noted that the permissions for /dev/sr0 seem to get reset. The permissions for /dev/sg4 are untouched. There are nothing relevant in the logs.

[J-miahL]

I looked through the logs and one thing stood out. 54-check-optical-drive.sh script execution returned "found optical drive [-, /dev/sg4], group 1000." I thought the script should return "/dev/sr0" vice "-". The permission is the same between sr0 and sg4. The next line states "WARNING: for best performance, the host device - needs to be exposed to the container". Both sr0 and sg4 were specified the same way, "--device /dev/sr0", --device /dev/sg4. If I run lsscsi -g, /dev/sr0 is missing.

[J-miahL]

if i edit /tmp/.drives_info and /tmp/.makemkv_supported would this correct the drive configuration of the container? Do i have to rerum the makemkv script. How can I correct the container configuration? (preferably through a shell)

[jlesage]

Looks like there is a permission issue with the devices. Could you share the full output of:

docker exec <container name> ls -l /dev/
docker exec <container name> lsscsi -g -k

[J-miahL]

grp1000 correlates with my Dockergroup and is granted rw permission to both sr0 and sg4. /Dev/sr0 is missing from the lsscsi command.

ls -l /dev/ returns the following: total 0 lrwxrwxrwx 1 root root 11 Jun 21 22:37 core -> /proc/kcore lrwxrwxrwx 1 root root 13 Jun 21 22:37 fd -> /proc/self/fd crw-rw-rw- 1 root root 1, 7 Jun 21 22:37 full drwxrwxrwt 2 root root 40 Jun 21 22:37 mqueue crw-rw-rw- 1 root root 1, 3 Jun 21 22:37 null lrwxrwxrwx 1 root root 8 Jun 21 22:37 ptmx -> pts/ptmx drwxr-xr-x 2 root root 0 Jun 21 22:37 pts crw-rw-rw- 1 root root 1, 8 Jun 21 22:37 random crw-rw---- 1 root grp1000 21, 4 Jun 21 22:37 sg4 drwxrwxrwt 2 root root 40 Jun 21 22:37 shm brw-rw---- 1 root grp1000 11, 0 Jun 21 22:37 sr0 lrwxrwxrwx 1 root root 15 Jun 21 22:37 stderr -> /proc/self/fd/2 lrwxrwxrwx 1 root root 15 Jun 21 22:37 stdin -> /proc/self/fd/0 lrwxrwxrwx 1 root root 15 Jun 21 22:37 stdout -> /proc/self/fd/1 crw-rw-rw- 1 root root 5, 0 Jun 21 22:37 tty crw-rw-rw- 1 root root 1, 9 Jun 21 22:37 urandom crw-rw-rw- 1 root root 1, 5 Jun 21 22:37 zero

lsscsi -g -k returns this [0:0:0:0] disk Seagate ST14000NM000J-2T SN02 - /dev/sg0 [1:0:0:0] disk Seagate ST14000NM001G-2K SN03 - /dev/sg1 [2:0:0:0] disk Seagate ST14000NM000J-2T SN02 - /dev/sg2 [3:0:0:0] disk Seagate ST14000NM001G-2K SN03 - /dev/sg3 [14:0:0:0] cd/dvd HL-DT-ST BD-RE BU40N 1.03 - /dev/sg4

[J-miahL]

Also I noted the sg.conf is not present

[jlesage]

/dev/sr0 is missing from the output of lsscsi, so it's not possible for the container to properly setup the device.

Do you have the same output if you run lsscsi -g -k directly on the host (I assume you are using a QNAP) ?

[J-miahL]

Yes, I have a QNAP. QNAPs do no have the lsscsi command, so I have no output with the lsscsi command. Interestingly enough, I realized my issue is very similar if not the same to Issue #168.

[jlesage]

Yes, I have a QNAP. QNAPs do no have the lsscsi command, so I have no output with the lsscsi command

• I assume that /dev/sr0 does exist in QNAP itself ?
• Do you have the same output (with missing /dev/sr0) when you run docker run --rm --privileged jlesage/makemkv lsscsi -g -k ?

Interestingly enough, I realized my issue is very similar if not the same to Issue https://github.com/jlesage/docker-makemkv/issues/168.

This issue was a problem with the download of keys. Do you see messages like Downloading latest SDF and/or Downloading latest HK in MakeMKV (as indicated in the issue)?

[J-miahL]

• Yes the /dev/sr0 exist on the QNAP itself.
• Yes I get the same output when I run docker run --rm --privileged jlesage/makemkv lsscsi -g -k
• I do get the "Downloading latest SDF" but not the latest HK. Below is the error I start to get.

003007:0000 Using direct disc access mode 005085:0000 Loaded content hash table, will verify integrity of M2TS files. DEBUG: Code 2147483648 at #mc>TV'5up=GaX"2:121265499 DAFD=PAAAADAAAAEABDQgEFwECAQ== 002004:0000 Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT PRESENT' occurred while issuing SCSI command A30..0020..03F to device 'SG:dev_21:4'

[J-miahL]

I did rule out it is not an inability to get the HK files

[jlesage]

Just for test purpose, if you run the container as root (i.e. with USER_ID=0 and GROUP_ID=0), do you still have the issue ?

[jlesage]

Do you have lsblk in QNAP ? If yes, do see sr0 when you run lsblk -r ?

[J-miahL]

lsblk is no longer available, apparently. I am pretty sure it use to be. I tried using the container in privilege and it did not fix the issue. I also tried using several previous versions, which had worked in the past. It did not work as well. A firmware upgrade must have changed this.

[J-miahL]

Would it be possible to specify the drive rather than the script?

[jlesage]

lsblk is no longer available, apparently. I am pretty sure it use to be.

You could try:

docker run --rm jlesage/makemkv sh -c "add-pkg lsblk && lsblk -r"

Note that the script is not doing anything useful except informing the user about detected drives. MakeMKV has its own mechanism to detect drives. If you tried with privileged mode and with USER_ID=0 and GROUP_ID=0 and it's still not working, then maybe there is a real issue with /dev/sr0. At least, this rules out any permission issues.

[J-miahL]

I tried a privileged container with USER_ID and GROUP_ID =0 and it did not work. I will try adding the lsblk package later tonight. appreciate your help. I also will note that at the end of the log it says I require a libredrive even though MakeMKV says enabled under status. It seems like something is preventing the drive from going to libredrive mode.

[J-miahL]

When I ran the docker run --rm jlesage/makemkv sh -c "add-pkg lsblk && lsblk -r" sr0 was listed.

[jlesage]

Could you share the output of the command ?

[J-miahL]

The output for sr is "sr0 11:0 1 56.6G 0 rom". The complete output is below.

fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/main/x86_64/APKINDEX.tar.gz fetch https://dl-cdn.alpinelinux.org/alpine/v3.16/community/x86_64/APKINDEX.tar.gz (1/1) Installing lsblk (2.38-r1) Executing busybox-1.35.0-r17.trigger OK: 347 MiB in 137 packages NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 12.7T 0 disk sda1 8:1 0 517.7M 0 part md9 9:9 0 517.6M 0 raid1 sda2 8:2 0 517.7M 0 part md256 9:256 0 517.7M 0 raid1 [SWAP] sda3 8:3 0 12.7T 0 part md2 9:2 0 38.2T 0 raid5 drbd2 147:2 0 38.2T 0 disk sda4 8:4 0 478.5M 0 part md13 9:13 0 448.1M 0 raid1 sdb 8:16 0 12.7T 0 disk sdb1 8:17 0 517.7M 0 part md9 9:9 0 517.6M 0 raid1 sdb2 8:18 0 517.7M 0 part md256 9:256 0 517.7M 0 raid1 [SWAP] sdb3 8:19 0 12.7T 0 part md2 9:2 0 38.2T 0 raid5 drbd2 147:2 0 38.2T 0 disk sdb4 8:20 0 517.7M 0 part md13 9:13 0 448.1M 0 raid1 sdb5 8:21 0 8G 0 part md322 9:322 0 6.9G 0 raid1 [SWAP] sdc 8:32 0 12.7T 0 disk sdc1 8:33 0 517.7M 0 part md9 9:9 0 517.6M 0 raid1 sdc2 8:34 0 517.7M 0 part md256 9:256 0 517.7M 0 raid1 [SWAP] sdc3 8:35 0 12.7T 0 part md2 9:2 0 38.2T 0 raid5 drbd2 147:2 0 38.2T 0 disk sdc4 8:36 0 478.5M 0 part md13 9:13 0 448.1M 0 raid1 sdd 8:48 0 12.7T 0 disk sdd1 8:49 0 517.7M 0 part md9 9:9 0 517.6M 0 raid1 sdd2 8:50 0 517.7M 0 part md256 9:256 0 517.7M 0 raid1 [SWAP] sdd3 8:51 0 12.7T 0 part md2 9:2 0 38.2T 0 raid5 drbd2 147:2 0 38.2T 0 disk sdd4 8:52 0 517.7M 0 part md13 9:13 0 448.1M 0 raid1 sdd5 8:53 0 8G 0 part md322 9:322 0 6.9G 0 raid1 [SWAP] sr0 11:0 1 56.6G 0 rom nbd0 43:0 0 0B 0 disk nbd1 43:32 0 0B 0 disk nbd2 43:64 0 0B 0 disk nbd3 43:96 0 0B 0 disk nbd4 43:128 0 0B 0 disk nbd5 43:160 0 0B 0 disk nbd6 43:192 0 0B 0 disk nbd7 43:224 0 0B 0 disk mmcblk0 179:0 0 3.7G 0 disk mmcblk0p1 179:1 0 16M 0 part mmcblk0p2 179:2 0 224M 0 part mmcblk0p3 179:3 0 224M 0 part mmcblk0p5 179:5 0 8M 0 part mmcblk0p6 179:6 0 8M 0 part fbsnap0 251:0 0 0B 0 disk fbsnap1 251:1 0 0B 0 disk fbsnap2 251:2 0 0B 0 disk fbsnap3 251:3 0 0B 0 disk fbsnap4 251:4 0 0B 0 disk fbsnap5 251:5 0 0B 0 disk fbsnap6 251:6 0 0B 0 disk fbsnap7 251:7 0 0B 0 disk fbdisk0 252:0 0 0B 0 disk fbdisk1 252:1 0 0B 0 disk fbdisk2 252:2 0 0B 0 disk fbdisk3 252:3 0 0B 0 disk fbdisk4 252:4 0 0B 0 disk fbdisk5 252:5 0 0B 0 disk fbdisk6 252:6 0 0B 0 disk fbdisk7 252:7 0 0B 0 disk nvme1n1 259:0 0 931.5G 0 disk nvme1n1p1 259:2 0 517.7M 0 part md9 9:9 0 517.6M 0 raid1 nvme1n1p2 259:3 0 517.7M 0 part nvme1n1p3 259:4 0 922G 0 part md1 9:1 0 1.8T 0 linear drbd1 147:1 0 1.8T 0 disk nvme1n1p4 259:5 0 517.7M 0 part md13 9:13 0 448.1M 0 raid1 nvme1n1p5 259:6 0 8G 0 part md321 9:321 0 7.9G 0 raid1 [SWAP] nvme0n1 259:1 0 931.5G 0 disk nvme0n1p1 259:7 0 517.7M 0 part md9 9:9 0 517.6M 0 raid1 nvme0n1p2 259:8 0 517.7M 0 part nvme0n1p3 259:9 0 922G 0 part md1 9:1 0 1.8T 0 linear drbd1 147:1 0 1.8T 0 disk nvme0n1p4 259:10 0 517.7M 0 part md13 9:13 0 448.1M 0 raid1 nvme0n1p5 259:11 0 8G 0 part md321 9:321 0 7.9G 0 raid1 [SWAP] nbd8 43:256 0 0B 0 disk nbd9 43:288 0 0B 0 disk nbd10 43:320 0 0B 0 disk nbd11 43:352 0 0B 0 disk nbd12 43:384 0 0B 0 disk nbd13 43:416 0 0B 0 disk nbd14 43:448 0 0B 0 disk nbd15 43:480 0 0B 0 disk

[jlesage]

How the drive is connected ?

[J-miahL]

The drive is connected to USB.

[jlesage]

Might be a power issue? Look at this: https://forum.makemkv.com/forum/viewtopic.php?t=24022

[J-miahL]

The drive is connected using the Y cable. I even have one end connecting directly to a power adapter. The funny thing is that it connects to my PC using a non Y cable and it works.

[jlesage]

So you have the issue even when the drive is plugged to a power adapter ?

Could you share the output of these commands:

docker exec <container name> /opt/makemkv/bin/makemkvcon -r --cache=1 info disc:9999

docker exec <container name> /opt/makemkv/bin/makemkvcon f --list

[J-miahL]

docker exec /opt/makemkv/bin/makemkvcon - r --cache=1 info disc:9999

MSG:1005,0,1,"MakeMKV v1.17.4 linux(x64-release) started","%1 started","MakeMKV v1.17.4 linux(x64-release)" MSG:3338,0,2,"Downloading latest SDF to /root/.MakeMKV ...","Downloading latest %1 to %2 ...","SDF","/root/.MakeMKV" DRV:0,2,999,12,"BD-RE HL-DT-ST BD-RE BU40N 1.03 ##############","HOUSE_OF_THE_DRAGON_S1_D1","/dev/sg4" DRV:1,256,999,0,"","","" DRV:2,256,999,0,"","","" DRV:3,256,999,0,"","","" DRV:4,256,999,0,"","","" DRV:5,256,999,0,"","","" DRV:6,256,999,0,"","","" DRV:7,256,999,0,"","","" DRV:8,256,999,0,"","","" DRV:9,256,999,0,"","","" DRV:10,256,999,0,"","","" DRV:11,256,999,0,"","","" DRV:12,256,999,0,"","","" DRV:13,256,999,0,"","","" DRV:14,256,999,0,"","","" DRV:15,256,999,0,"","","" MSG:5010,0,0,"Failed to open disc","Failed to open disc" TCOUNT:0

[J-miahL]

docker exec /opt/makemkv/bin/makemkvcon f --list

Found 1 drives(s) 00: dev_21:4, /dev/sg4, /dev/sg4 HL-DT-ST_BD-RE_BU40N_1.03211810241934###########

[J-miahL]

I rebuild the container and now I am getting a failure to download HK data in the log.

[J-miahL]

I replaced the _private_data.tar on the container with the version on my PC. The failure message went away but the drive still failed to open the movie

[jlesage]

The last 2 commands confirm that MakeMKV itself doesn't see/detect sr0. Did you run these with privileged/root container ?

I rebuild the container and now I am getting a failure to download HK data in the log.

What is the error ?

[J-miahL]

Yes I did run it as a privilege/root container. The log said downloaded fail or something of the sort. However, it disappeared when I modified the _private.tar file. Sr0 is pass onto the container, but for whatever reason the application cannot see it. Could it be that QNAP removed a service that the container previously depends on? I also notice when I use my PC the logs usually reports Libre mode or something of that nature. The container goes straight to direct access vice libre mode. I don't know what triggers the libre mode.

[J-miahL]

The firmware on the drive was the issue. I switch to the firmware the guys over at MakeMKV suggested and it works now. Thanks for all your help.

[jlesage]

Great, thanks for the update.