Linux GUI - 3 Bugs on Ubuntu 11.10

[thebiznatch]

Hi,

I've been a MakeMKV user for well over a year on Linux. The product has worked great on Ubuntu 10.10 for me. I recently upgraded (not a fresh install) to 11.10. I had upgraded to 1.7.0 on Ubuntu 10.10 and it was stable. After upgrading to Ubuntu 11.10 and not touching MakeMKV, 3 bugs now happen:

1. On my dual monitor setup, the "Advanced" properties don't show a dropdown for Filename, Name, etc. when click on a title, but only only on my 2nd monitor. If I drag the app over to my first monitor, the dropdown works. Strange...

2. After ripping a single disk, I can no longer use the "Eject" button directly on my bluray hardware. The eject button/icon inside MakeMKV doesn't work either. The only way I can eject a disk is to go into Ubuntu itself and tell it to eject the disk.

3. After ripping a single bluray disk, MakeMKV usually will start eating up all 16GB of my RAM, eventually starve my system (which doesn't have swap enabled since i have an SSD), crash Gnome, and then I need to reboot. I can only rip a single bluray disk and then it exhibits this behavior.

I think 2 and 3 are related in someway. Its weird that most of my serious bugs occur after a single disk has been ripped.

I'm not sure how else I can help debug this for you. Glad to turn on logging and try to trigger this for you (just need instructions).

[MI3Guy]

I'm running LMDE and am also experiencing #2. I haven't seen #3 although I haven't been looking and I'm only using a single monitor so I can't reproduce #1.

[BrionS]

I've found the "Eject" button in MakeMKV will cause a fatal error if pressed while using Advanced Mode. A dialog pops up stating a fatal error has occurred and the program will now close, but if you dismiss that dialog the UI does indeed disappear but the makemkv process in the background will remain and begin consuming all available memory and swap until the computer is completely unresponsive.

It doesn't happen all the time, but probably 9 times out of 10 it does. When it happens, the way I found to preemptively stop the runaway process is to open a terminal window and kill the makemkv processes. The side effect of doing this is the BD drive tray cannot be ejected by the drive button. I need to re-launch MakeMKV and then the drive opens.

This is extremely annoying but since I have a workaround I can get by. This does not happen at all if Advanced Mode is not checked but then I cannot do many things I like to do such as customize the .mkv file name to be created and select which audio and subtitle tracks I want it to rip.

I have not tested to see if this happens when the entire disc is ripped at once as a backup copy instead of ripping a single title to .mkv.

@thebiznatch what video driver are you using (with regard to problem #1)? I've got a dual head set-up and have no problems. I have an NVidia card and use the proprietary drivers. At work I have an AMD video card and find the proprietary drivers are crap with 11.10 and have since rolled back to just the open source radeon drivers which is still good enough for compositing and desktop effects but not good enough for games.

[mike admin]

Is this still the case with 1.7.2 ?

[BrionS]

I've built 1.7.2 but haven't tried it yet. Will do so this weekend and let you know.

[BrionS]

I have not had it crash on me yet. If it does crash, I'll give you the log and do my best to describe the conditions under which it crashed. Thanks!

[marmoset]

#2 (eject button no longer works) is happening for me with 1.7.2, using makemkvcon in vortexbox fwiw.

[marmoset]

To be more specific, the hardware eject button on the blu ray drive no longer works. /usr/sbin/eject still works fine (as well as /usr/sbin/eject -t)

[BrionS]

I've found the hardware button has never worked to eject the disc while MakeMKV is in control of the drive(s). This was especially a problem in the previous version when MakeMKV needed to be killed to avoid it running amok after a crash but in doing so the drive remained "locked" until I re-launched MakeMKV and pressed the eject button while it was starting up. That usually allowed the drive to open and then I could quit the program again.

I will check and see if my drive button is also non-functional while running MakeMKV but as long as the software eject works I'm not too concerned.

[marmoset]

Hi,

It happens even after makemkvcon is finished, so once I've ripped something with it, I'm unable to use my hardware eject button until I power cycle the machine, which is obviously less than ideal for a headless machine dedicated to ripping my movies

Moses

[marmoset]

And by finished, I mean, it exited and is no longer running. I need to be better about details the first time around.

[marmoset]

Figured out a workaround, can do eject -i 0 /dev/sr0 (or whatever device), and presumably echo 0 > /proc/sys/dev/cdrom/lock as well, it must be getting set back to zero when makemkvcon exits.

let me know if I can provide any further info to debug.

Thanks,

Moses

[BrionS]

I guess I'm a little bit curious as to why MakeMKV is locking the drive in the first place. Can't it be notified when someone presses the eject button and cancel its current operation? Failing that, if it can no longer read from the device, can't it assume the disc has been ejected and either prompt the user to re-insert the disc to continue or fail gracefully by aborting the current operation?

If it didn't lock the drive it wouldn't have to worry about unlocking the drive on exit and we wouldn't find ourselves in the situation where the application has crashed hard and didn't release the lock. It's completely counter-intuitive to non-techies (especially non-Linux techies) for the eject button to not work once the program is ended (killed or otherwise).

[marmoset]

I'm not convinced it's makemkv doing it fwiw. My vortexbox has been happily ripping audio cds for over a year with the eject button working just fine. I swapped in a blu ray drive a week or two ago, and saw the eject button issue. I added the eject -i 0 in the vortexbox script after the routines for ripping movies, and it worked great. Then today I ripped an audio cd, and the eject button was dead afterwards.

I'll add the eject -i O after the audio cd ripping as well, but maybe it's not makemkv, but rather something different about how the kernel or system libraries handle blu rays?

[mike admin]

I guess I'm a little bit curious as to why MakeMKV is locking the drive in the first place. Can't it be notified when someone presses the eject button and cancel its current operation? Failing that, if it can no longer read from the device, can't it assume the disc has been ejected and either prompt the user to re-insert the disc to continue or fail gracefully by aborting the current operation?

If it didn't lock the drive it wouldn't have to worry about unlocking the drive on exit and we wouldn't find ourselves in the situation where the application has crashed hard and didn't release the lock. It's completely counter-intuitive to non-techies (especially non-Linux techies) for the eject button to not work once the program is ended (killed or otherwise).

This is not done on purpose. MakeMKV never sends lock command to the drive. Apparently it does something that forces the OS to lock the drive, but what is it exactly is unknown at the moment.