www.makemkv.com

ewanmarkus wrote: Wed Jul 08, 2026 12:38 pm Hi all,

I'm trying to enable LibreDrive on an HL-DT-ST BD-RE BU40N for UHD backups and have hit a wall that doesn't match the usual failure modes. Hoping dcoke22 / MartyMcNuts / Billycar11 or anyone with A1xx experience can point me in the right direction.

Drive / setup
- HL-DT-ST BD-RE BU40N, firmware A102 (firmware date 2017-12-01 17:08), platform MT1959
- Connected over USB (machine has no SATA ports). Tested through two different USB-SATA bridges: ASMedia ASM1153E (174C:1153) and a JMicron bridge (152D:0583), both enumerating as USBSTOR (BOT)
- MakeMKV v1.18.4, Windows 11, makemkvcon run elevated
- MakeMKV drive info: LibreDrive: Possible, not yet enabled; Bus encryption flags: 1F; Highest AACS version: 82

Firmware file
HL-DT-ST-BD-RE_BU40N-1.03-NM00000-211810241934.bin from the "all you need firmware pack" (2,097,152 bytes, SHA256 64900E8D69212F5D729B9DFA45EF0F317378DB8C8B48083A7CB99831235B5D57). Note: makemkvcon reports "Image already has DE byte set" when the de flag is used.

The symptom
Every single flash attempt completes both phases ("Sending flash image to drive" 100%, "Programming flash" 100%) and ends with "Done successfully", exit code 0. After a full power cycle (USB unplugged, drive re-enumerated, confirmed via fresh device arrival timestamps), the drive still reports A102. No error is ever raised: no 0x82052603 rollback error, no "Write DRAM NG", nothing. Nine attempts total across both bridges:

Code: Select all

rawflash enc            (auto-selected "Using USB chipset workaround for Desktop drive handshake")
rawflash enc,slim       ("Using an USB slim drive handshake")
-f sdf.bin rawflash enc,slim
-f sdf.bin rawflash de,enc,slim
SDFtool Flasher v1.3.6, normal flash
SDFtool Flasher, with "Include boot" (on the first bridge)
plus earlier permutations of the above on the first bridge

Other observations
- Vendor-level reads work fine: MakeMKV successfully dumped and auto-uploaded the drive firmware for analysis (dump_FW_1BE3BD032CAD14D0F7B8.tgz), so the bridges pass vendor commands in at least the read direction
- "makemkvcon f -d X: dump full" is not available: dump auto only yields the user-data area (~70 KB), so full ROM dump appears disabled by this firmware
- With a UHD disc inserted (MKB v82): "Can't read AACS VID from disc - most likely current AACS host certificate is revoked by your drive" followed by "LibreDrive compatible drive is required to open this disc"
- The drive reads CDs/DVDs/regular Blu-rays perfectly; it has never bricked despite all these attempts

My working theory
A102 looks like the ASUS OEM firmware (SBW-06D5H-U family). It seems to accept the flash image, ack every write, and then silently discard it at commit, rather than raising the rollback error seen in viewtopic.php?t=41801 (same A102 + MT1959 combo).

Questions
1. Is A102 known to silently ignore flash images over USB? Is there any DE/unlock-enabled intermediate image for A1xx that actually commits?
2. Is there anything in my command lines above that would explain "success but no change" other than firmware-side rejection?
3. Or is this drive simply a dead end for LibreDrive, and I should go the paid-flash route or replace the drive?

Happy to provide full logs or re-run any diagnostic. Thanks!

ewanmarkus wrote: Wed Jul 08, 2026 11:47 pm Solved, thank you MartyMcNuts. You nailed it: dropping enc was the fix.

For anyone who finds this later with the same "Done successfully but no change" symptom on an A102 / MT1959 BU40N: every one of my attempts had been using enc, and the drive silently discarded each one. The moment I flashed the plaintext image with no enc flag:

Code: Select all

makemkvcon64.exe f --all-yes -d E: rawflash -i "HL-DT-ST-BD-RE_BU40N-1.03-NM00000-211810241934.bin"

it committed on the first try. After a power cycle the drive now reports 1.03 (was A102), LibreDrive shows enabled, and a UHD disc opens cleanly (77 titles, zero "KEY EXCHANGE FAILURE", no "LibreDrive compatible drive is required"). The tell in the log: with enc you get a "Sending image in encrypted format" line; without enc that line is gone and it just works.

Thanks also to RibShark for the boot-code lead. For the record, in case it helps someone else: I did work through all of those boot codes (BUP5 / BU5 / BU51 / BUP1 / BUP3 / BP32 / BP52) plus the drive's own factory code, each verified with a full power cycle, and none committed while enc was in play. So on this drive it was purely the enc flag, not a boot-code mismatch.

Really appreciate the help, both of you. 4K ripping is up and running.