www.makemkv.com

System:
- Debian 13 (trixie), kernel 6.12.107+deb13-amd64
- MakeMKV 1.18.4, built from source (makemkv-oss + makemkv-bin), GUI (Qt5) + makemkvcon

Drive: ASUS BW-16D1HT, firmware 3.11
Enclosure: OWC Mercury Pro Optical (USB bridge, VID:PID 1e91:de2c)

Symptom:
`makemkvcon -r info disc:0` hangs indefinitely with no output beyond the
startup message. Debug log (--debug=) shows it hangs right after starting
automatic drive-capability detection:

No SDF v0a6: ASUS_BW-16D1HT_3.11_212012011759_KL5P48B5603
SDF auto v0a6: ASUS_BW-16D1HT_3.11_212012011759_KL5P48B5603

No further lines are ever written after "SDF auto ...". Full debug log
attached (MakeMKV_log.txt). Reproduced consistently across two different
commercial Blu-ray discs.

What I've ruled out:
- Empty drive tray: works instantly and correctly (full DRV: listing,
clean error for invalid disc index). Only hangs once a disc is
physically loaded and this auto-detection step is reached.
- Root privileges: `sudo makemkvcon -r info disc:0` hangs identically.
Rules out CAP_SYS_RAWIO / SG_IO permission restrictions.
- USB speed: tested at both USB 3.0 (5000M, native port) and USB 2.0
(480M, via a USB2-only port). Identical hang in both cases.
- Kernel quirks: checked drivers/usb/storage/unusual_devs.h and
unusual_uas.h (v6.12) — no entry for VID 1e91. Driver bound is plain
`usb-storage` (Bulk-Only Transport, bInterfaceProtocol=80); the device
offers no UAS alternate interface at all.
- KEYDB.cfg: tested both with and without a KEYDB.cfg present in
~/.MakeMKV/ — no difference in behavior.
- Competing processes: `lsof /dev/sr0 /dev/sg0` shows no other process
holding the device; udisks2 is running but not actively polling during
the test.
- Drive power-cycle (full unplug/replug of the enclosure): no change.

Kernel-level observation:
`sudo dmesg -w` shows *zero* new lines during the entire hang — no USB
resets, no SCSI errors/timeouts, nothing. The kernel/USB layer appears
completely unaware of any problem.

Process behavior during hang:
`ps -o pid,stat,wchan,pcpu` shows the makemkvcon process at ~98-100% CPU,
wchan cycling through `hrtimer_nanosleep` — consistent with an
application-level poll/retry loop rather than a blocked kernel I/O wait.
/proc/<pid>/fd shows an open handle on /dev/sg0.

Cross-check:
- The exact same drive + exact same enclosure works correctly with
MakeMKV on Windows.
- VLC (libbluray/libaacs/libbdplus) on this same Linux machine reads,
decrypts and plays the same disc through the same drive without
issue, so the disc and drive are not physically at fault.

My guess: the "SDF auto" drive-capability probe (LibreDrive detection?)
sends a vendor-specific command sequence that this particular USB bridge
either doesn't pass through correctly or responds to in a way the Linux
build doesn't handle (no kernel-level error is generated either way, so
whatever is sent/received "succeeds" at the transport level but the
parsing/state machine on the MakeMKV side never completes). Happy to
provide strace or any other diagnostics if useful.

regards
Einkauf

Short answer : Any Linux makemkv-bin version above 1.17.7 has a broken firmware tool, MakeMKV is trying to make a firmware dump of a non-LibreDrive-compatible firmware and is unable to do so.

Short solution : Switch to the last known stable Linux makemkv-bin version (1.17.6, but you can also try 1.17.7 - no need to change the oss version, you can keep that one at 1.18.4) then :

1) Open a disc in MakeMKV, wait until the firmware dump is created, then switch back to makemkv-bin-1.18.4

OR

2) Remove any disc from the drive, flash your drive to make it LibreDrive/UHD compatible, then switch back to makemkv-bin-1.18.4

My guess: the "SDF auto" drive-capability probe (LibreDrive detection?)
sends a vendor-specific command sequence that this particular USB bridge
either doesn't pass through correctly or responds to in a way the Linux
build doesn't handle (no kernel-level error is generated either way, so
whatever is sent/received "succeeds" at the transport level but the
parsing/state machine on the MakeMKV side never completes). Happy to
provide strace or any other diagnostics if useful.

Actually, if you are correct, this could be very useful to the author. You can attempt to provide the full MMC/SCSI command kernel logs if you would like, and if you cannot I will probably try to do so myself with an "unflashed" BP55EB40 at some point. (How to get the correct logs : run "scsi_logging_level -s --all 7" as root then look at the output of "dmesg")

EDIT : Hmm, I just tried it and well, I am now wondering if it might be helpful to get the ATA logs as well, but I do not know how to do so at the moment. This might require further research.

Thanks for the explanation! Downgrading makemkv-bin to 1.17.6 (keeping makemkv-oss at 1.18.4) fixed it completely.

I captured full SCSI logging (scsi_logging_level -s --all 7 + dmesg) around the hang. Here's the key finding:

Last commands issued by makemkvcon via /dev/sg0 before it goes silent:

CDB: Read Buffer 3c 06 00 00 30 00 00 00 20 00 -> SUCCESS (32 bytes)
CDB: Write Buffer 3b 06 00 00 00 00 00 00 10 00 -> SUCCESS (16 bytes)

(Write Buffer mode 0x06 = "Download microcode with offsets, save, and
activate" - matches the firmware dump/write step you described.)

Both commands complete successfully (SUCCESS, hostbyte=DID_OK,
driverbyte=DRIVER_OK). Immediately after that Write Buffer completes,
makemkvcon never issues another command through /dev/sg0 again - the
only further activity in the log is the kernel's own periodic media-poll
(Get Event Status Notification every ~2s, not tagged [sg0], i.e. not
coming from makemkvcon), confirming the drive and kernel stay fully
responsive and idle for the rest of the hang.

So it looks like the firmware write/activate itself succeeds at the
hardware level, but makemkvcon's internal state machine afterwards
never proceeds - it just spins at ~98% CPU (confirmed separately via
ps/wchan) waiting on something that never resolves, rather than timing
out or reporting an error. This matches your diagnosis of the firmware
dump path being broken in current makemkv-bin for non-LibreDrive
firmware.

Thank you very much for confirming what I suspected, the firmware dump crash is the exact same as the one for every other makemkvcon f command.

Since non-flashing, non-dumping makemkvcon f commands also crash in the same fashion (such as the "list MT1959 flashing commands" command, "makemkvcon f -n -t mtk19xx help"), I think it is safe to assume that this is indeed some kind of endless while loop or something like that.

Write Buffer mode 0x06 = "Download microcode with offsets, save, and
activate"

This is irrelevant to this discussion and I am really nitpicking for the sake of nitpicking (sorry about that ), but according to the sg_write_buffer man page this is slightly incorrect : it's actually "Download microcode with offsets and activate (was called "Download microcode with offsets" in SPC-3)." You were thinking of 0x07, I believe, which is "Download microcode with offsets, save, and activate (was called "Download microcode with offsets and save" in SPC-3)."

EDIT : By the way, you should probably still switch back to makemkv-bin-1.18.4 now that you've got your firmware dump (and you can switch back to 1.17.6 yet again whenever you need the firmware tool). As Marty explained to me, 1.17.6 does not natively handle AACS v82 discs, which means that they may give you a headache unless you give MakeMKV a valid VUK for that disc with the KEYDB.cfg file (Marty explained to me that when using an older version of MakeMKV, you *have* to use KEYDB.cfg to decrypt AACS v82 discs - and I would assume the same would be true with a revoked certificate for v82 : when that happened to me, I had to use KEYDB.cfg as well despite using MakeMKV... 1.18.2; I believe, which supports AACS v82. LibreDrive makes the certificate revocation irrelevant and can potentially allow you to read UHD discs as well, provided they are officially supported or KEYDB.cfg has the VUK for them, and provided you have a compatible drive, of course; which should be the case for you).