Linux SDF initialization hang — HL-DT-ST GBC-H20N C102 (MakeMKV 2.0.0)

[JCLatt24]

Hello MakeMKV developers,

I'm seeking a safe, supported workaround for a Linux initialization hang with an HL-DT-ST DVDRWBD GBC-H20N, firmware C102, connected via native SATA/ATAPI to Ubuntu 24.04.4 LTS (x86_64; Linux 7.0.0-38 HWE). The optical drive is /dev/sr0 and its SCSI generic node is /dev/sg1. Blu-ray media such as Frozen II are detected correctly by the OS as UDF discs.

MakeMKV 1.18.4 and an isolated installation of official MakeMKV 2.0.0 hang during drive discovery (makemkvcon info disc:9999 / info dev:/dev/sr0), consuming approximately 96–98% of one CPU core without reporting DRV entries or titles. A prior 1.18.3 installation has been preserved unchanged. Kernel logs show no optical I/O errors associated with these attempts. The hang may involve SDF/LibreDrive initialization, but this cause has NOT been definitively demonstrated.

An isolated test using a root-created systemd DevicePolicy=strict sandbox grants /dev/sr0 and /dev/sg1 read-only opens and removes all process capabilities; mock device-policy checks passed. Under this protection, 'makemkvcon -f --list' exited successfully but reported 'Found 0 drives(s)' because libdriveio attempts to open /dev/sg1 with O_RDWR|O_NONBLOCK and is refused. No firmware commands were issued during that read-only discovery attempt. Granting O_RDWR merely to satisfy discovery is not considered safe: the Linux sg driver conditionally applies its legacy scsi_cmd_allowed check to read-only descriptors, so dropping CAP_SYS_RAWIO alone does not prove firmware-changing commands would be blocked. I have not enabled writable access, altered firmware, or performed further physical MakeMKV testing.

Your documentation describes Sdf_stop/SDF_STOP as an emergency brake for LibreDrive activity on an exact drive identifier. I can collect standard INQUIRY vendor/model/revision and udev serial privately, but MakeMKV has never returned the precise SDF identifier; asking MakeMKV to list it enters the problematic open/discovery path.

Could a MakeMKV developer please clarify:
1. Can the exact SDF_STOP drive identifier for GBC-H20N C102 be obtained or constructed offline from standard inquiry fields? If so, what exact safe procedure and syntax should be used? I can provide the serial and raw INQUIRY privately if requested.
2. Is SDF_STOP evaluated BEFORE any writable SG device open or firmware-related SCSI command (especially WRITE BUFFER, opcode 0x3B), even during initial discovery? Is this verified for this drive/firmware?
3. Is there an official setting to disable SDF/LibreDrive before device probing, while retaining ordinary Blu-ray reads?
4. Is a corrected official Linux build or another vendor-supported, firmware-safe discovery procedure available for this model?

I can share sanitized debug logs privately. I am not seeking a firmware flash. Thank you.

[tomty89]

The value sdf_Stop expects should show up in the log file (which should be produced after your enabled debugging). See viewtopic.php?p=203364#p203364 as an example.