Libredrive Compatibility (UHD Disc Only)
J-miahL opened this issue · comments
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.
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.
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)
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
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
Also I noted the sg.conf is not present
/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) ?
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.
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/sr0does 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 #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)?
- 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'
I did rule out it is not an inability to get the HK files
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 ?
Do you have lsblk in QNAP ? If yes, do see sr0 when you run lsblk -r ?
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.
Would it be possible to specify the drive rather than the script?
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.
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.
When I ran the docker run --rm jlesage/makemkv sh -c "add-pkg lsblk && lsblk -r" sr0 was listed.
Could you share the output of the command ?
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
How the drive is connected ?
The drive is connected to USB.
Might be a power issue? Look at this: https://forum.makemkv.com/forum/viewtopic.php?t=24022
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.
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
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
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.03_211810241934_###########
I rebuild the container and now I am getting a failure to download HK data in the log.
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
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 ?
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.
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.
Great, thanks for the update.