Resolution of key exchange failures - external USB?

[efoobar]

I'm running makemkv 1.10.4 on Slackware 14.1 with two different LG drives indicating support of AACS v61 (one internal SATA, the other external USB).

The internal drive appears to be working without issue.

However, the external USB drive (LG BP50NB40) is giving me the key exchange failures as shown below (and elsewhere in this forum) on any disk I try in it. Is this an issue inherent in USB drive operation or is there a new technology/feature that makemkv isn't yet able to work around? The disk being tested shows as using AACS v32, but even v16's do this as well.

Code: Select all

....
Error 'Scsi error - ILLEGAL REQUEST:COPY PROTECTION KEY EXCHANGE FAILURE - KEY NOT ESTABLISHED' occurred while issuing SCSI command AD010..080002400 to device 'SG:dev_11:1'
DEBUG: Code 0 at 62bCYeE@[@_#ky8 uj:29396345
DEBUG: Code 4 at 62bCYeE@[@_#ky8 uj:121262647
Can't read AACS VID from disc - most likely current AACS host certificate is revoked by your drive
Highest AACS version is v61 , MKB saved as /root/.MakeMKV/MKB_v61_TIME_STAND_STILL.tgz
The volume key is unknown for this disc - video can't be decrypted
...

Going off other (older) forum posts, I see some users fixing their own installation errors and such but a lot of cold threads that don't get resolved. Is this sort of issue any better understood at this point in time...?


Thanks,
-e.

[Woodstock]

The key seems to be to allow MakeMKV to access the drive with full privileges under the user you're running it as. This does NOT mean running it as root or using sudo, if you can add the device to your user's control.

When MakeMKV does the key exchange, if it isn't allowed full access, the drive never receives the key, and gives you the key exchange error.

External USB devices can be an issue, because they aren't persistent. When you unplug it or or restart the system, the device stops existing, so its settings may not still be there next time.

[efoobar]

Unless you're thinking of something I'm not, that shouldn't be the issue here. Testing has included running as root, and the devices are instantiating correctly (well, good enough anyway):
brw-rw---- 1 root cdrom 11, 0 Mar 13 21:28 /dev/sr0
brw-rw---- 1 root cdrom 11, 2 Mar 13 21:29 /dev/sr2

Just for shiggles I gave it o+rw as well, but as expected no change.

Any other ideas?