Having some ripping trouble with a new ASUS BW-16D1HT

[mikeymikec]

Hi all,

I have two BR drives in my computer, the first I bought in 2020 which happens to be the same model number as the one I bought nearly a month ago:

Older drive (call it drive 1): ASUS BW-16D1HT, Revision: 3.10
New drive (drive 2): ASUS BW-16D1HT, Revision: 3.11
MakeMKV version: 1.18.2
Primary OS: Linux Mint Cinnamon 21.1
Secondary OS: Win11

I downloaded a firmware update at least a year ago to LibreDrive enable drive 1, but I think the only reason I did that was to allow it to handle UHD discs, I don't recall any trouble like what I'm having with drive 2, being that MakeMKV can't even identify a disc. Linux can, and I can browse the filesystem. In Windows, I can play back some new discs I've bought on drive 2, so IMO there's no question that the drive works in a warranty sense (though I have not tested writing yet).

In my experience, VLC BR playback between Windows and Linux can be a case for a given disc that Linux VLC reliably can play the disc and/or Windows VLC can, but MakeMKV in Linux has (and does) consistently worked with the older drive, and did ID one of the new discs without any issue. I think drive 2's firmware is stopping it working with MakeMKV. MakeMKV just sits and waits for forever acting like it's reading the disc but doesn't. I end up having to end the process manually.

This is what it's log file says:

Code: Select all

Debug log started at Fri Jan  2 18:31:43 2026 , written by MakeMKV v1.18.2 linux(x64-release)
001005:0000 MakeMKV v1.18.2 linux(x64-release) started
001004:0000 Debug logging enabled, log will be saved as file:///home/mike/MakeMKV_log.txt
Using 262272KB for read cache.
Network access is ENABLED, CURL version 7.81.0/OpenSSL/3.0.2/1.43.0 (x86_64-pc-linux-gnu) , proxy server not set.
001003:0020 DEBUG: Code 0 at [$&!cPHsNoNC,vJT%<05$ :29393631
SDF  v0a4: ASUS_BW-16D1HT_3.10_211901041014_KLIK6F91816
No  SDF v0a4: ASUS_BW-16D1HT_3.11_212012011759_KL5P84E4104
SDF id v0a4: ASUS_BW-16D1HT_3.11_212012011759_KL5P84E4104

- edit - I've since updated MakeMKV on Windows and it can ID discs in drive 2 without issue, so this looks like a MakeMKV on Linux issue.

Side note: In case anyone is wondering why I have two drives, I noticed that supply of drives (at least to the UK) is unreliable and seems to be dwindling to nothing. I'm quite invested in having a film DVD/BR collection and I rip the discs for personal use only (so I can easily watch them on my computer), and in my experience optical drives eventually die so I thought I'd hedge my bets by having a second drive and split the load of reading any discs I get in future between the two drives in the hope that I get more life out of each.

[mikeymikec]

Further updates: I've ripped a disc in MakeMKV/Windows on drive 2 without any issue.

In Linux I tried single drive mode, then after that I tried renaming ~/.MakeMKV so the configuration files were started from scratch. Neither action helped.

[Stingray]

KL5P84E4104 - It seems it was MFD in 2025/08

[MartyMcNuts]

Hi all,

I have two BR drives in my computer, the first I bought in 2020 which happens to be the same model number as the one I bought nearly a month ago:

Older drive (call it drive 1): ASUS BW-16D1HT, Revision: 3.10
New drive (drive 2): ASUS BW-16D1HT, Revision: 3.11
MakeMKV version: 1.18.2
Primary OS: Linux Mint Cinnamon 21.1
Secondary OS: Win11

I downloaded a firmware update at least a year ago to LibreDrive enable drive 1, but I think the only reason I did that was to allow it to handle UHD discs, I don't recall any trouble like what I'm having with drive 2, being that MakeMKV can't even identify a disc. Linux can, and I can browse the filesystem. In Windows, I can play back some new discs I've bought on drive 2, so IMO there's no question that the drive works in a warranty sense (though I have not tested writing yet).

In my experience, VLC BR playback between Windows and Linux can be a case for a given disc that Linux VLC reliably can play the disc and/or Windows VLC can, but MakeMKV in Linux has (and does) consistently worked with the older drive, and did ID one of the new discs without any issue. I think drive 2's firmware is stopping it working with MakeMKV. MakeMKV just sits and waits for forever acting like it's reading the disc but doesn't. I end up having to end the process manually.

This is what it's log file says:

Code: Select all

Debug log started at Fri Jan  2 18:31:43 2026 , written by MakeMKV v1.18.2 linux(x64-release)
001005:0000 MakeMKV v1.18.2 linux(x64-release) started
001004:0000 Debug logging enabled, log will be saved as file:///home/mike/MakeMKV_log.txt
Using 262272KB for read cache.
Network access is ENABLED, CURL version 7.81.0/OpenSSL/3.0.2/1.43.0 (x86_64-pc-linux-gnu) , proxy server not set.
001003:0020 DEBUG: Code 0 at [$&!cPHsNoNC,vJT%<05$ :29393631
SDF  v0a4: ASUS_BW-16D1HT_3.10_211901041014_KLIK6F91816
No  SDF v0a4: ASUS_BW-16D1HT_3.11_212012011759_KL5P84E4104
SDF id v0a4: ASUS_BW-16D1HT_3.11_212012011759_KL5P84E4104

- edit - I've since updated MakeMKV on Windows and it can ID discs in drive 2 without issue, so this looks like a MakeMKV on Linux issue.

Side note: In case anyone is wondering why I have two drives, I noticed that supply of drives (at least to the UK) is unreliable and seems to be dwindling to nothing. I'm quite invested in having a film DVD/BR collection and I rip the discs for personal use only (so I can easily watch them on my computer), and in my experience optical drives eventually die so I thought I'd hedge my bets by having a second drive and split the load of reading any discs I get in future between the two drives in the hope that I get more life out of each.

Lots of people have truoble with MakeMKV v1.18.2 on Linux. Go back to v1.17.7.