www.makemkv.com

1) makemkv locks the drive against ejects while it is active. It would be an improvement if it only locked the drive while a rip was in progress.

2) makemkv handles multiple drives very poorly. It always grabs the first device. If a second copy is opened to operate on a second drive, it is necessary to kill it's autoscan of the first device. It can then be set to use the second drive. So far so good, however, if the disk is ejected, makemkv reverts to the first device again and the scan has to be killed again. I worry about it affecting the first copy of makemkv already doing a rip on the first device.
The feature suggestion would be to set the drive to default to via a command line option.

I agree with #2 I wish there was a way to set the drive you wanted the instance of makemkv to use from the command line. Right now my work around for stopping the two instances of makemkv from stepping on one another is I log in as two different users and give each one exclusive access on the drives.

Edit: It would also be nice if there was a way to configure makemkv run a script on completion. It would also be nice if there were a few variables that could be passed to the script e.g. dvdname.

Love the software keep up there good work, worth the $50.

About 10 releases later, and makemkv still gets it's panties in a bind when multiple instances are open.
All of them try to open the first drive. One has to either wait 5 minutes for them to get over their bullish behavior, or kill each one about six times.

How freaking hard would it be to put a command line parameter for the default drive, or at the very least, turn off start up autoscan?

Makemkv also still locks drives it isn't using. I'll have it operating on another drive, and k3b will complain that it can't burn to a different drive because makemkv has a handle on it.

You can select a drive and disable auto-scan if you use command-line version.

mike admin wrote:You can select a drive and disable auto-scan if you use command-line version.

That's kind of like telling somebody who has taken their car in for a shimmy that they can walk. It is probably not news for them that they have feet and not a real solution.

I'm somewhat aware of the command line version and don't think it is terribly effective to use a method that requires ten to thirty times more user effort in order to get around a defect in the UI.

How hard would it be to have a command line parameter on makemkv to have it use a particular drive?
I can't imagine it taking more than about 10 lines of code.

About ten releases later and this nasty bug still hasn't been fixed.
If you start multiple instances makemkv, they will all try try to simultaneously access all drives and tie themselves into a knot.
Each one has to have the red X hit about ten times to unclaw them.

I've eventually come up with a workaround. Start them one at a time. Let each one settle down and then switch it to desired drive before starting the next. This allows work to commence within about 20 seconds instead of 5 minutes of constant fighting.

It would be better if the makers of makemkv would simply fix the bug. I've seen their code and it is extremely ugly. I think I know why they won't touch the startup code.

This is already fixed in makemkvcon.

The fix is coming to MakeMKV gui as well - there is already a hidden setting (io_SingleDrive , not yet fully working). If enabled, MakeMKV will start in "single drive mode". It will open and present a list of drives as usual but will not scan them. The moment you do anything with the drive (open,backup, eject) or manually select it, MakeMKV will release all other drives and will operate only with selected drive.

I know this is an old thread, but I wanted to resurrect it to thank mikeadmin for working on this in spite of the "encouragement" above. I can report that I didn't notice any change in behaviour after creating an io_SingleDrive=1 registry DWORD value on Windows 7 64 bit. Regardless of the presence of this value, makemkv always scans both my drives when it starts up and is quite happy to eject or start using a drive in use by another instance.

However, I have not found the situation to be unworkable for multiple drives. If you manage your instances correctly, the initial drive scan is the only point of contention between them. Even this can be avoided by starting as many instances as you need BEFORE you start any of them ripping. For the times when you forget to do this, and have already started an instance ripping, you can quickly hit the "stop" button on the scanning process of the newly started instance ONCE and wait for the drives to stop freaking out with gibberish debug messages. The integrity of the other instance's rip operation will be unharmed even if the same cannot be said about its momentary performance.