Buffalo 16X not reading/Stalling

[Not-so-great-at-this]

# MakeMKV info/read hangs indefinitely on all discs (Blu-ray AND DVD) - Ubuntu, LG BH16NS58/Buffalo BRXL-16U3

## Summary

`makemkvcon info disc:0` (and `dev:/dev/sr0`) hangs indefinitely after printing the
startup line, on every disc I've tried (Blu-ray and standard DVD alike). No crash,
no error - the process just sits there consuming ~100% CPU on one thread forever,
until manually killed. This happens consistently across many hours of testing and
a long list of environmental changes (below), all of which made no difference.

**The exact same physical drive and disc work perfectly fine ripping via MakeMKV on
a Windows laptop** - so this is very likely something specific to this Linux
environment or to this MakeMKV Linux build, not the disc or drive hardware itself.

## System info

- OS: Ubuntu (kernel 7.0.0-29-generic)
- MakeMKV version: 1.18.4 linux(x64-release), installed via the
`ppa:heyarje/makemkv-beta` PPA
- Drive: Buffalo BRXL-16U3 (external USB), internally an LG/HL-DT-ST BD-RE
BH16NS58, firmware revision 1.03, stock (not flashed)
- Drive info from a prior working session:
```
Manufacturer: HL-DT-ST
Product: BD-RE BH16NS58
Revision: 1.03
Bus encryption flags: 1F
Highest AACS version: 61
LibreDrive Information: Status: Possible, not yet enabled
```

## What happens

```
$ makemkvcon info disc:0
MakeMKV v1.18.4 linux(x64-release) started
[hangs here indefinitely - no further output, no error, no crash]
```

Same result with `makemkvcon info dev:/dev/sr0` (bypassing disc-index discovery
entirely).

On one occasion, waiting long enough resulted in:
```
Failed to open disc
Total 0 titles
```
...but this was not consistently reproducible, and mostly the process just hangs
forever with no output at all.

## strace findings

Attaching `strace -p <PID> -f` to the process while hung shows the main thread
doing nothing but an infinite polling loop:

```
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=50000000}, NULL) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=0, tv_nsec=50000000}, NULL) = 0
[repeats indefinitely, every ~50ms, no other syscalls]
```

Using `ps -eLf` to find the actual busy worker thread (98-100% CPU, separate from
the polling main thread) and attaching strace directly to *that* thread with
`-T` (to show syscall duration) showed the exact same clock_nanosleep(50ms) loop -
no reads, writes, ioctls, or any SCSI/MMC-level communication with the drive
visible at all, despite that thread showing real, sustained CPU usage.

## Things I've ruled out (tested individually and in combination)

- **udisks2 automount conflict**: confirmed via `mount | grep sr0` and dmesg
(`Can't open blockdev` racing with `UDF-fs: INFO Mounting volume...`) that
udisks2 was grabbing the device. Fixed with a udev rule
(`ENV{UDISKS_IGNORE}="1"` matched on the drive's USB vendor/product ID). Made
no difference to the hang either way (tested with the rule present and absent).
- **Leftover/zombie processes**: found and killed multiple orphaned
`makemkvcon guiserver` background processes (one still running >7 minutes,
99% CPU, from an earlier failed GUI launch attempt) that were accumulating
across test attempts. Killing everything with `pkill -9 -f makemkv` and
starting completely fresh made no difference.
- **Network/DNS connectivity**: confirmed working (`ping 8.8.8.8` and
`ping google.com` both succeed with normal latency, ~11-25ms).
- **TLS/SSL version**: curl 8.18.0 / OpenSSL 3.5.5, both current; forcing
`--tlsv1.2` explicitly made no difference (this was tested for a *separate*
issue - makemkv.com's own download server returning Cloudflare 525 errors on
both wget and curl - but ruled out TLS as a factor generally).
- **`sdf_Stop` setting**: found `sdf_Stop = ""` in `~/.MakeMKV/settings.conf` and
set it to `"1"` based on an old forum thread about SDF-download hangs. No
change in behavior.
- **USB autosuspend**: checked `/sys/bus/usb/devices/<drive>/power/control` -
already `"on"` (never suspends), not the cause.
- **USB 3.0 vs USB 2.0**: physically moved the drive from a USB 3.0 (SuperSpeed,
Bus 2) port to a USB 2.0 port (Bus 1, confirmed via `lsusb`/speed file).
Kernel log had shown a forced `usb reset SuperSpeed USB device` event during
an earlier hang, which looked promising, but the hang was identical on
USB 2.0.
- **usb-storage vs UAS driver**: confirmed via dmesg
(`usb-storage 2-2:1.0: USB Mass Storage device detected`) that the drive
uses the legacy `usb-storage` driver, not `uas` - so this isn't an UAS
compatibility issue.
- **Disc type**: hangs identically on both a Blu-ray and a standard DVD.
Rules out anything AACS/Blu-ray-specific.
- **Local firewall**: `ufw status` returns `inactive`.
- **Driver/module loading**: `usb_storage` module confirmed loaded;
xhci_hcd controller initializes cleanly at boot with no errors in dmesg.

## Cross-check with a different tool

To isolate whether this was drive/system-level or MakeMKV-specific, I tried
`HandBrakeCLI -i /dev/sr0 --scan` on the exact same drive/disc/system.
**HandBrake successfully opened the device and began scanning** - it got to
`keydbcfg.c:701: No valid AACS configuration files found` (expected, since I
don't have libbluray's AACS keys set up - not something I'm looking to solve
via HandBrake, just wanted to confirm the drive/USB/system stack itself is
functional). This is nowhere near the "hangs silently forever with zero I/O"
behavior MakeMKV shows - HandBrake reached a specific, clean error almost
immediately.

This strongly suggests the drive, USB connection, and OS-level SCSI/MMC access
are all working correctly, and the hang is specific to how this MakeMKV Linux
build communicates with this drive.

## Additional notes

- Also attempted to remove the PPA install and build from official source
(`makemkv-oss-1.18.4.tar.gz` / `makemkv-bin-1.18.4.tar.gz`) to rule out a
PPA-specific packaging bug, but makemkv.com's own download server is
currently returning Cloudflare 525 (SSL handshake) errors on every attempt
(via both wget and curl, with modern TLS/OpenSSL), so I was unable to
complete this comparison. Reinstalled via the PPA to get back to a working
baseline install.
- Happy to provide any further diagnostics (additional strace output,
ltrace, gdb backtrace of the hung thread, etc.) - just let me know what
would be useful.

Any help figuring out what's actually blocking this would be genuinely
appreciated - this is the last piece blocking a fully-local home media server
setup that everything else is already working for.