Low-priority bug: µTorrent 2.x'ish restarts incorrectly after upgrade.

[bumpycars]

µTorrent must be manually restarted; prior to 2.x µTorrent could successfully update itself.

Windows XP SP3

Setup:

Torrents: Two copies of µTorrent run in the same session. One mostly seeds a few high-priority items (utorrent1.exe) and the other handles bulk transfers (utorrent2.exe). Discrimination between them favours bandwidth for seeding the priority items over bulk. The priority copy of µTorrent is named 'utorrent1.exe' on disk and the bulk is 'utorrent2.exe'. Both are started from different folders with /RECOVER. CFOS (a traffic shaper) can shape application traffic based on executable name alone -the reason for different .exe names. The 'utorrent1.exe' is set for 'low' traffic priority (between normal and above the lowest), where 'utorrent2.exe' has a 'lowest' priority.

The above set-up works very well, and I feel it is clearly within the design criteria of µTorrent. And it used to work grand. Definitely pre-2.x clients, the client could upgrade itself, close itself down and re-start itself as the new build #. The other client was not affected.

Now:

Get the pop-up to update µTorrent, for the priority/utorrent1 copy, and click 'Yes'.

The utorrent1.exe *is* updated on disk, then instead of utorrent1 restarting itself with the same set of original parameters, the updater calls to the foreground the remaining running µTorrent, utorrent2.exe. I have to minimize utorrent2.exe and manually start utorrent1.exe (/RECOVER).