GUI does not start #1805

Closed
eba869 opened this Issue Nov 7, 2016 · 14 comments

Projects

None yet

3 participants

@eba869
eba869 commented Nov 7, 2016

Hi, mkvtoolnix-gui does not start at all. I have read through a previous issue and ensured that the folder is not a 'read-only' folder. It still does not start. Can you help, please?
Many thanks!

@mkver
Contributor
mkver commented Nov 7, 2016

You should give more information if you want help on this issue: What is your OS? What version of MKVToolNix do you use? You aren't mixing different versions, are you? Did older versions work for you? (I mean a version older than the current one, but still new enough to include the GUI based on qt; everything after version 8.0 includes the new GUI if I'm not mistaken.)

@mbunkus
Owner
mbunkus commented Nov 7, 2016

First of all make sure that it's not your Anti Virus program that's preventing the execution. I've had several reports over the last couple of weeks of people who haven't been able to run one of my programs because their AV solution wrongly identified my programs as malicious. After whitelisting mkvtoolnix-gui.exe and mkvmerge.exe things magically started working again.

@eba869
eba869 commented Nov 12, 2016

Hi,

Sorry to take so long to thank you for your reply and to provide more info. I have been fishing around trying to solve this to no avail. However, I have seen to that the program is allowed on my machine and I run Windows 10.

Initially the version of MKVToolNix I had was working fine and the day after it did not. So I uninstalled it and installed the latest version 9.5.0 from the website. That did not help. Actually - I have uninstalled and reinstalled twice, last time was today. I ensured everything was gone before I reinstalled. But still - it does not open.

I checked Windows updates too in case something changed the accessablity there but there was no update after 30/10 at the time so that is not the issue either.

So, what else can I do?

Thank you for helping me.

Eva


From: mkver notifications@github.com
Sent: Tuesday, 8 November 2016 2:34 AM
To: mbunkus/mkvtoolnix
Cc: eba869; Author
Subject: Re: [mbunkus/mkvtoolnix] GUI does not start (#1805)

You should give more information if you want help on this issue: What is your OS? What version of MKVToolNix do you use? You aren't mixing different versions, are you? Did older versions work for you? (I mean a version older than the current one, but still new enough to include the GUI based on qt; everything after version 8.0 includes the new GUI if I'm not mistaken.)

You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mbunkus/mkvtoolnix/issues/1805#issuecomment-258867992, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWOX42-k0F7q_B7f-farkRuPzYGW3jbjks5q70TqgaJpZM4Kq0QU.

@mbunkus
Owner
mbunkus commented Nov 12, 2016

Alright. Please follow the steps laid out in this FAQ entry. Thanks.

@eba869
eba869 commented Nov 14, 2016

Hi, so I have one file that was created. How do I get it to you? I tried server as stated in the FAQ but it just says 'This site can't be reached'.

Thanks

Eva

@mbunkus
Owner
mbunkus commented Nov 14, 2016

You can send me the file via email to moritz@bunkus.org

@mbunkus
Owner
mbunkus commented Nov 14, 2016

Thanks for the log file.

  1. First please make sure that no other process named mkvtoolnix-gui.exe is running (via the task manager → "details" tab).
  2. Now make sure that the following directory actually exists: C:\Users\eba86\AppData\Local\Temp.
  3. Next make sure that the directory is owned by the user eba86 and that the user eba86 has full access (especially write permission) to that directory.
  4. If there's a file called MKVToolNix-GUI-Instance-Communicator.lock Inside that directory, remove it.
  5. Start DebugView.exe again and set up logging to a file just like before.
  6. Now try to start the GUI again (the debug build, please). If it comes up then one of the steps before has solved your issue. If not send me the file created in step 5.
@eba869
eba869 commented Nov 14, 2016

Hi again,

  1. Done
  2. It dies
  3. Not sure about this one. For some reason there are "EVA" and "eba869@hotmail.com" :

[cid:dd63b771-65d8-4b64-b358-41dc6ae95d7b]

Does this screen tell you anything useful?
4. Nope, I cannot find a file with that name.
5. Sending the log file but since I didn't do any changes......

Thank you again [😊]

Eva


From: Moritz Bunkus notifications@github.com
Sent: Monday, 14 November 2016 8:20 PM
To: mbunkus/mkvtoolnix
Cc: eba869; Author
Subject: Re: [mbunkus/mkvtoolnix] GUI does not start (#1805)

Thanks for the log file.

  1. First please make sure that no other process named mkvtoolnix-gui.exe is running (via the task manager → "details" tab).
  2. Now make sure that the following directory actually exists: C:\Users\eba86\AppData\Local\Temp.
  3. Next make sure that the directory is owned by the user eba86 and that the user eba86 has full access (especially write permission) to that directory.
  4. If there's a file called MKVToolNix-GUI-Instance-Communicator.lock Inside that directory, remove it.
  5. Start DebugView.exe again and set up logging to a file just like before.
  6. Now try to start the GUI again (the debug build, please). If it comes up then one of the steps before has solved your issue. If not send me the file created in step 5.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/mbunkus/mkvtoolnix/issues/1805#issuecomment-260285397, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWOX42O5GhhUZLsZiGkS20T_2I3f4m5sks5q-CfTgaJpZM4Kq0QU.

@mbunkus
Owner
mbunkus commented Nov 14, 2016

Github doesn't show the screenshot you seem to have sent, therefore I cannot comment. Please drag & drop the screenshot into the web GUI to upload it properly.

I'm almost certain that the permissions on the folder are wrong. What's the user name you're using to log into Windows?

@mbunkus
Owner
mbunkus commented Nov 22, 2016

eba869 wrote via email:

So I contacted Microsoft to see if they could check permissions but
mainly tell me why I have two usernames. Anyway, the permissions are
now sorted out but MKVToolNix still doesn't work. Anymore ideas of
what I can do?

@mbunkus
Owner
mbunkus commented Nov 22, 2016

Well, you can follow the procedure with DebugView I've outlined above once more, but my guess is that the GUI can still not write into your temporary directory due to wrong permissions. MKVToolNix isn't the only program that requires the temp directory to be present and writable.

@eba869
eba869 commented Nov 23, 2016

Well, the same version of MKVToolNix worked perfectly with the same permissions before so something else has changed but I lack the knowledge to figure out what.

@mbunkus
Owner
mbunkus commented Nov 23, 2016

Alright, please follow these steps:

  1. Make sure no instance of MKVToolNix GUI is running by either looking at the task manager or by simply rebooting.
  2. Download and install the new debug build I've just uploaded.
  3. Go do C:\Users\<yourUsername>\AppData\Local\Temp and remove any file whose name starts with MKVToolNix.
  4. Start DebugView.
  5. Try starting the new debug build you've just installed.
  6. Send me the output generated in DebugView if the GUI doesn't come up.
@mbunkus
Owner
mbunkus commented Dec 2, 2016

Closing due to lack of feedback.

@mbunkus mbunkus closed this Dec 2, 2016
@mbunkus mbunkus added a commit that referenced this issue Dec 8, 2016
@mbunkus GUI: don't use lock file for instance communication socket
The lock file has proven to be a source of problems time and again on
Windows, see e.g. #1805. In most instances a stale lock file was still
present though the process it referred to wasn't running anymore. Qt is
supposed to clean up such stale lock files automatically, but that
didn't work reliably. The result from the user's POV was that the GUI
simply didn't start as neither the prior instance was still running nor
was the new one showing its UI.

Therefore we just skip trying to lock that file. Instead the new
instance will simply try to connect to the communication socket. If that
connection succeeds, it can be reasonably sure another instance is
running. If it fails, though, the GUI simply removes any lingering
socket file and tries to set it up again. Even if the removal &
subsequent setup fails, the GUI should still come up as a second
instance.
d302897
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment