Strange method to get it to open bluray: close app, open app

[mrpipikinsphrey]

I have a new bluray now: BD-RE ATAPI eHBU312 2 VL12 (liteon), much better speed (4-times better or more). I have to use a strange method to get it to open bluray:

1. 1st bluray: put in disk, makemkv opens it perfectly in DASPI
2. Insert second bluray, makemkv cannot open
3. Close makemkv - with the bluray still in drive - and then open makemkv; the bluray can now be opened

I have to do this little juggle each time. I'm using a mac; how'd I more forward to address this, do you advise?

Further, what I mean by this is that it does not even allow you to click the image of the drive to begin opening the bluray - it is greyed-out; and in the info, just says 'data'. Like i said, closing and opening makemkv fixes this.

If I use OS access mode instead, this does not happen; I'm able to click the image of the disc to open it, but, unlike the DASPI mode, the protection level and all disc information is blank, yet it opens and rips fine.

Thanks kindly
Andrew



Debug log started at Tue Mar 12 10:13:41 2013 , written by MakeMKV v1.8.0 darwin(x86-release)
Using 524544KB for read cache.
001005:0000 MakeMKV v1.8.0 darwin(x86-release) started
001004:0000 Debug logging enabled, log will be saved as /Users//MakeMKV_log.txt
002014:0000 Optical drive "BD-RE ATAPI eHBU312 2 VL12" opened in DASPI v1.3 mode.
001003:0020 DEBUG: Code 0 at I80bg8&E=3WCWsA]Fhe=30jk":213131318
DEBUG: Code 0 at HUGUO>l{uNf&c<It%j$U2h@hR:213130536
001003:0020 DEBUG: Code 0 at I80bg8&E=3WCWsA]Fhe=30jk":213131318
DEBUG: Code 0 at HUGUO>l{uNf&c<It%j$U2h@hR:213130536
001003:0020 DEBUG: Code 0 at I80bg8&E=3WCWsA]Fhe=30jk":213131318
DEBUG: Code 0 at HUGUO>l{uNf&c<It%j$U2h@hR:213130536

[Smithcraft]

I believe there is an issue with 1.8.0 where if the disc isn't ready when MakeMKV is launched it doesn't see the disc. The recommended procedure is to close MakeMKV and reopen MakeMKV.

SC

[mrpipikinsphrey]

Indeed. Makemkv gives up just before disc is mounted on desktop.

[mike admin]

Yes, it's a confirmed bug in 1.8.0