Windows v1.6.16 still says it is v1.6.15

[joe42]

MakeMKV v1.6.15 win(x64-release) started

Downloaded and installed Windows MakeMKV 1.6.16, but it still claims to be v1.6.15.

In the about box, it says MakeMKV v1.6.15, GUI version v1.6.16

[Woodstock]

You probably did not make sure that the command line portion was stopped before doing the install.

If you don't want to reboot your computer first (the usual way to fix Windows ), you can open the task manager, and find any makemkv tasks that are still running, and end them.

Then, re-run the install, and it should correct the problem.

There are some circumstances where the CLI won't stop, even when you shut down the GUI. If you click the disk eject icon and nothing happens, you have to kill the CLI yourself.

If you have logging turned on, you will see the log file name will have a number in it if the previous session didn't close.

[joe42]

You probably did not make sure that the command line portion was stopped before doing the install.

Thanks, that was it. The installer did not warn me that the install failed, even though I now know that it did. After rebooting and re-running the installer, I now have v1.6.16 displayed.

And you even guessed the cause (I think). I did recently click the eject icon and nothing happened. I think in the future I will avoid that buggy eject icon, and press the manual button on the drive.

[Woodstock]

Unfortunately, the eject button isn't the cause - it's a symptom. Even if you don't use the button, when whatever causes the issue happens, closing MakeMKV just doesn't close down the CLI. It doesn't happen as often as it did a few versions ago.

For some reason, when the CLI program reaches the end of a rip, it is still talking to the DVD/BD, so the drive is "busy" when you try to eject. Because the CLI is "busy", it won't stop when it's told to. Zapping it with the task manager seems to be the only thing it listens to, because you can't initialize another rip at that point without stopping the GUI.

When you restart the GUI, it starts a separate copy of the CLI, leaving the original one running in the background. With logging turned on, the log file name will get a 1 appended to it when this happens, because the original log is still locked by the first process.

Could be worse - when this first started happening, you'd get an "Application Failed to Initialize" error when you did the install!