A little late to the party, but maybe this helps someone. I had the exact same issue last night. Finally got around to upgrading from v1.15.1 to v1.15.3 to attempt some DV rips.
Win 10 1903
Asus BW-16D1HT v3.01
To date I've successfully ripped 140+ UHDs following the same procedure, with very few actual failures, all due to visibly scratched media. Otherwise, 100% success across several versions of MakeMKV.
My process is like this:
1. Open retail packaging
2. Wash hands to remove oil
3. Remove UHD disc from packaging
4. Place 3 drops of Dawn dish detergent and clean, center to outside, with warm water and rinse
5. Wipe clean, center to outside, with a clean microfiber cloth (always washed with Chemical Guys microfiber cleaner)
6. Insert disc into drive
7. Wait for OS to acknowledge disc (discs are often unreadable if I do not)
8. Run MakeMKV as admin
9. Rip disc
I'm quite fastidious about this, and have very few issues.
So I recently purchased a few new titles and set to ripping with MakeMKV. The first titles were fine, no issues as usual. Part way through, I was perusing the forum and noticed the latest Dolby Vision capabilities, which I've been pretty excited for, so I upgraded. Also, for the first time, I installed the CD-ROM arbiter service. I totally get why it's there, so why not.
After cleaning, the first disc I pop in is one of two new titles I've yet to rip with DV. The first thing I notice is that the drive is making some pretty unhappy seeking noises upon loading the disc. Then, it takes several tries for the OS to recognize there's a disc in the drive. The OS eventually recognizes the disc it and I start MakeMKV. MakeMKV seems to take longer than usual to decrypt the disk and again makes some unhealthy seek noise, but ultimately opens. Upon attempting to load the titles, which again takes longer than usual, I see a pile of these below, and more noise from the drive:
DEBUG: Code 2399219969 at 514U4Qpim*J{}UjC?:29397219
DEBUG: Code 2399219969 at 514U4Qpim*J{}UjC?:213132399
DEBUG: Code 1 at 514U4Qpim*J{}UjC?:29396920
DEBUG: Code 2399211777 at 514U4Qpim*J{}UjC?:213132399
DEBUG: Code 2 at 514U4Qpim*J{}UjC?:29396920
DEBUG: Code 2399211777 at 514U4Qpim*J{}UjC?:213132399
DEBUG: Code 3 at 514U4Qpim*J{}UjC?:29396920
DEBUG: Code 2399211777 at 514U4Qpim*J{}UjC?:213132399
DEBUG: Code 4 at 514U4Qpim*J{}UjC?:29396920
DEBUG: Code 0 at yv"y}$N<9>6(HCzT:29396920
After a number of minutes, the disc finally fails to open citing hash issues. Ok, unusual, but maybe it's a bad disc. I'm prepared to send it back to Amazon and then load the next disc, still excited to try to get a DV rip.
Next, I load another new disc with DV. Again, unhealthy noise from the drive, seems to hang for several moments during decrypting phase. The application then hangs during processing titles. I give it time, as the application is not responding, though the disc audibly spinning. Elapsed/remaining time is frozen, though the application never errors out. Finally, it fails to load the disc, again with hash errors.
Encountered 15212 errors of type 'HashCheck Error' - see
http://www.makemkv.com/errors/hashcheck/...
Failed to open disc
OK, fine, I've been in IT for 20 years, and I know there's a couple of truths: 2) There are no coincidences, and 2) A new problem is nearly always a result of the thing that changed most recently. So I uninstall v1.15.3, reboot, and roll back to MakeMKV 1.15.1, this time opting to not install the arbiter service, to return things to the way they were. Unfortunately, there was no change in behavior, it was still a steaming mess.
So I now try one of the new discs without DV (not that it matters) that I just ripped with v1.15.1 before upgrading and rolling back. No dice - it's behaving just like the others. That's when I noticed something odd - the arbiter service is still running. So I kill it. When I do, no discs are recognized. As in, at all. The drive doesn't even indicate there is a disc present in the OS and the light on the drive continuously flashes after a disc is inserted. Clearly there's some dependency here I'm not aware of.
So, I did the only other reasonable thing - I rolled back via System Restore. Drive is now working as before, clean UHD rips, no debug errors, no hash errors. After testing in v1.15.1, I upgraded to v1.15.3 and the drive continues to work fine. Clearly not the drive, clearly not the disc. Others have reported rare, but similar mishaps after upgrades and found a reinstall of Windows solved it for them, though a System Restore if enabled is certainly quicker. I'm really not sure what about this process could cause such an issue, but we are talking about software and a service that issues SCSI commands to hardware, so who knows.
A couple of questions for Mike:
1. Why isn't the arbiter service/process stopped/removed when the application is uninstalled?
2. Why the strange behavior when I kill the arbiter process?
3. Clearly a Windows service is calling the arbiter process, but I do not see a proper Windows service in the MMC, though it's listed in services in the Task Manager. sc query shows the following, so again, why am I not seeing it in the MMC?
SERVICE_NAME: CdRomArbiterService
DISPLAY_NAME: CdRom Device Arbiter service
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, ACCEPTS_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
Thanks!
Is this a faulty Asus model that stops working if you are not using it for 6 months? How can I make it back to it's senses and start reading the disks that it burned? Please any suggestion would be precious! Thank you in advance! Razvan.