When start qbittorent from its own shortcut or from an associated .torrent file, it starting an additional instance of the process in windows 7 x64, instead of use the already running one.
The problem occur only if I start the app from qBittorrentPortable.exe.
When I start from "\App\qBittorrent\qbittorrent.exe" (whats start method is not portable), and start another instance (from app start or from associated files), it will appear only a torrent add dialog in the app, or happen nothing.
The qBittorrent devs redirected to here about that issue, coz that portable is not officially supported, and the problem is not in the qbittorrent app itself, they states.
You are here
[Fixed] qBittorrent multiple instance
September 18, 2012 - 10:36am
#1
[Fixed] qBittorrent multiple instance
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on Facebook
Follow us on LinkedIn
Follow us on Twitter
Follow us on Mastodon
Follow us on BlueSky
When you pass a command line to qBittorrentPortable.exe when it is already running, all we do is pass it off to qbittorent.exe, nothing more. The portablization of qBittorrent is pretty straightforward as it provides no portablization methods at all (no command line or environment variables) so all we do is let qBittorrent store its stuff like it always does in the registry and APPDATA and move that onto and off of the PC. So, the launcher isn't doing anything special. It's just launching qbittorrent.exe with the command line you pass in.
Sometimes, the impossible can become possible, if you're awesome!
I don't know where the issue is, but its fact I able to start multiple instance from "qBittorrentPortable.exe" (process qbittorrent.exe will duplicates), but I can't start duplicates from "qbittorrent.exe" directly.
Everybody states the problem is in the other part, but the issue still remains anyway...
I'm still struggling with this. I've created this post in the qBittorrent forums: http://qbforums.shiki.hu/index.php?topic=961.0#msg3823
This seemed to be useful:
So basically isRunning looks for a specially named lockfile inside %TEMP% directory and that's all.
Do you know if this is being checked?
Indeed the PAP version is creating a new instance. The original version does not. I've added 2 different torrents from the command line and on the original version the second one gets added to the list while in the PAP version the new instance of qBittorrent gets created.
Is there any way to allow only one instance of the qBittorrent portable launcher? Probably that way there will only be one instance of qBittorrent itself.
Any idea would be helpful. Thanks.
As mentioned above, we make no changes and pass no command lines to qBittorrent itself (other than what you give us), just backup the existing local setting (if any), load the portable ones where qBittorrent is expecting to find them and then start it up.. As an experiment, I started up qBittorrent Portable using qBittorrentPortable.exe. I then dropped a torrent file onto qbitorrent.exe within qBittorrentPortable\App\qbitorrent. It spawned a new instance of qBitorrent instead of passing the file off to the already-running copy. Not sure why, as it should have detected that it is already running, so perhaps we should find out how qBittorrent is determining that it is already running and passes a file off to itself. Other apps like Firefox don't have this issue and their launchers work the exact same way. Actually, nearly all our apps work this way.
Sometimes, the impossible can become possible, if you're awesome!
Made the same test you just did and got the same results you got. Then it is a matter of qBittorrent guys.
I looked for the code (its in C++ and that is a language I don't speak at all), but when scanning this file:
https://github.com/qbittorrent/qBittorrent/blob/master/src/qtsingleapp/q...
I noticed an interesting comment:
By default, the full path of the executable file is used to determine whether two processes are instances of the same application. You can also provide an explicit identifier string that will be compared instead.
I'm not sure what this is talking about but when running both processes they have the same executable file... so I guess somehow that default behaviour is being overriden by an explicit identifier, as the documentation mentions.
Probably someone out there can keep investigating this
In theory, then, it should have the same identifier when launched from the portable launcher or not. In practice, it does not. If we could get someone from qBittorrent who is more familiar with this code to offer guidance, perhaps. But, yes, the problem does indeed seem to be with qBittorrent itself and how it determines if it is already running.
Sometimes, the impossible can become possible, if you're awesome!
I'm using a launcher I made in NSIS (for other purposes) to execute the original qbittorrent.exe file found in the \App\qBittorrent\ directory.
The launcher only executes the qBittorrent.exe file using the "Exec" function of NSIS. I executed it many times and only one instance of qBittorrent is beign spawned, so this is actually make me wonder if this is really on qBittorrent side.
I can provide the code of my launcher, if you think that would help. Thanks
There is other stuff going on within PAL, but if qBittorrent is doing what it is documented to do (unique AppID based on location of their running EXE) then it shouldn't matter. Instead, qBittorrent is getting something from the running environment and adding that to the AppID. We're not purposely adding anything and not passing it any commandline except what you pass to the qBittorrentPortable.exe launcher. In fact, if qBittorrent worked as they are explaining it works, then it should be impossible to spawn a second instance regardless of command line or environment variables.
We do this process with hundreds of other apps. It's only qBittorrent that is having this issue. So it's not using the EXE's location as the unique identifier, it's using something else instead of or in addition to that that is confusing it. There's no virtualization going on in the portable launcher, which should theoretically be the only thing that could cause this situation.
Sometimes, the impossible can become possible, if you're awesome!
Ok, I read through the message ( http://qbforums.shiki.hu/index.php?topic=961.0#msg3823 ) and now understand qBittorrent's kinda hacky way of ensuring a single instance runs. Try adding this to your qBittorrentPortable.ini in App\AppInfo under the [Launch] section:
CleanTemp=false
That will cause qBittorrent not to have a contained (and cleaned) TEMP directory and will allow it to run as a single instance. I haven't yet tested if it will leave stuff behind as a result (it may). For future reference, the preferred way of ensuring an app runs a single instance on Windows is via a Mutexes. We use that in our apps and most Windows software seems to use it as well.
Sometimes, the impossible can become possible, if you're awesome!
This indeed did the trick. (The actual path is App\AppInfo\Launcher)
Probably, qBittorrent is doing it this way because they are targetting other OS, not only Windows (I actually use Debian as my main OS and use qBittorrent there too).
So far, I've associated the .torrent files to qBittorrentPortable.exe in the registry and started opening .torrent files. They're all getting added to the same instance instead of creating a new one.
Thanks for the quick and accurate support you've provided, John. I'll keep testing this new configuration and will report back if I find any issue... however, I'm pretty sure this will work and probably see an official update of the launcher
Thanks again!
This was fixed in qBittorrent Portable 3.0.4 released on Sept 23, 2012.
Sometimes, the impossible can become possible, if you're awesome!
Hi John,
I don't see this fixed in 3.0.6. After downloading it I had to update the config file myself. Thanks.
It's refixed in 3.0.6 Rev 2. Sorry about that.
Sometimes, the impossible can become possible, if you're awesome!
Sadly, it is broken again since version 4: If I open a .torrent file, a second instance is launched.
This is fixed in 4.0.2 Rev 2. The CleanTemp directive was removed in 4.0 and 4.0.1. It's been re-added and added to the github store of configurations to ensure it will remain.
Sometimes, the impossible can become possible, if you're awesome!
Works! That was a quick one. Thanks a lot!
You're welcome. Sorry about the regression.
Sometimes, the impossible can become possible, if you're awesome!