Starting Mumble twice clears all Whisper/Shout shortcuts #1797
Comments
|
i've noticed that this seams to be a windows issue.. when you try to open the second client of mumble, windows tries to rewrite the configs since the existing ones are in use. can i ask why you need to have two clients running? do you have a bot system that uses the second client? if it is a bot system there are alternatives to the mumble client it's self that you can get on the wiki. there is even a headless client that you could point your bot at instead of the standard client. |
|
I have absolutely no reason to run it twice. But sometimes the launch is delayed by I/O or cpu load, so we try to launch the shortcut again. It's entirely user-fault, but should also be avoidable. For example, I have the shortcut bound to my M1 key on my BlackWidow keyboard. I can press the button and if nothing happens, maybe Razer Synapse missed the press or who know what. So pressing again is a natural response. Or even under normal circumstances, the button could b pushed by a child or cat. Could a mutex be employed to prevent the double-launch? Is there ever a use-case for multiple copies. |
|
Can I get a bump on this? It looks like there is already code to prevent multiple copies. However, that code isn't given a chance to trigger if the second copy is launched before the first is loaded. To be clear, I am not asking for multiple copies, and my shortcuts do not use the "-m" modifier to allow it. If we can't fix the multiple copies issue, can we fix the settings nuking? |
|
We should use a Windows mutex to ensure that only a single client is able to start. The current RPC-based method is evidently racy. |
|
We should also fix the settings nuking issue. |
|
Thanks Mikkel. I'd love submit a pull request myself, but C++ is not very much not my specialty. |
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listning for RPC. And the exclusitivity check fails. In order to be completely sure that only a single Mmuble instance is running, we now take a lock file. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inacessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listening for RPC. And the exclusivity check fails. In order to be completely sure that only a single Mumble instance is running, we now take a lock file. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inaccessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
|
PR at #2037 |
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listening for RPC. And the exclusivity check fails. In order to be completely sure that only a single Mumble instance is running, we now take a lock file. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inaccessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listening for RPC. And the exclusivity check fails. In order to be completely sure that only a single Mumble instance is running, we now take a lock file. The lock file logic is implemented in a new class, UserLockFile. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inaccessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listening for RPC. And the exclusivity check fails. In order to be completely sure that only a single Mumble instance is running, we now take a lock file. The lock file logic is implemented in a new class, UserLockFile. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inaccessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listening for RPC. And the exclusivity check fails. In order to be completely sure that only a single Mumble instance is running, we now take a lock file. The lock file logic is implemented in a new class, UserLockFile. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inaccessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
mkrautz
added a commit
to mkrautz/mumble
that referenced
this issue
Dec 27, 2015
The RPC/DBus-based method for ensuring that only a single instance of Mumble is running is racy. If one of the processes has started it's RPC listener, it works fine. But if both processes are started at almost the same time, it's very likely that neither process has started listening for RPC. And the exclusivity check fails. In order to be completely sure that only a single Mumble instance is running, we now take a lock file. The lock file logic is implemented in a new class, UserLockFile. We open a lock file file in the data directory (for Windows, that's %APPDATA%\Mumble). The file has sharing disabled, so as long as the process that created the file is running, no other process can access it. If a second instance of Mumble is launched, and the file is inaccessible, that instance terminates itself. It is, of course, still possible to override the single instance limitation by passing the '-m' flag to Mumble. Fixes mumble-voip#1797
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
All my clanmates report this same issue. Sometimes we notice our whisper shortcuts are missing. The pattern we've found is that if the mumble client is started twice - by accident, of course - they disappear completely.
We're setup so that our PTT keys talk to our immediate channel, and we have a Shout to talk to the root channel and subchannels. This allows us to setup two-team communication, so we can talk to either only our team or everybody. When even one person's shout breaks, it causes us gameplay headaches.
The text was updated successfully, but these errors were encountered: