Add a way to safely close the client via command-line

[ajones81]

Using uTorrent 2.0.17920

As of now, if the 'Minimize on Close' option is selected, than using taskkill or pskill or similar results in a forced shutdown of the client, resulting in a prolonged disk check on next run that is entirely unnecessary and obviously not recommended for the HDD.

I'd like to know if there's a way I can shutdown the client gracefully/safely using the command-line. I want to automate when uTorrent starts and closes during the day using batch files or maybe even the Windows task scheduler or a 3rd party program. But if no such command-line option exists, I'd like to recommend that a new /CLOSE option be added that will simply close the program safely, as if File > Exit (or Exit from the tray icon context menu) had been clicked.

[adgrimes]

Second this. I use CLI to control utorrent and would love to be able to do this too...

Thanks

/ag

[andronics]

I would also like to second this, as I'm currently running µTorrent as a service. Which shutting down system causes µTorrent not to end cleanly.

[Ultima]

http://forum.utorrent.com/viewtopic.php?id=34067

[ajones81]

Interesting utility certainly. Too bad it requires .Net, since I primarily need to use it on a PC which cannot have the .Net framework installed on it for various reasons. Still, ought to come in handy for my other PCs.

This still shouldn't prevent uTorrent from having an in-built /CLOSE command-line option BTW. Why rely on external utilities when the app. can do it itself? Frankly, I can't really see any reason not to have this.

[Switeck]

And I can think of a few cases where it needs to have this. We've gotten reports that uTorrent has become unkillable using external utilities.

[Ultima]

Having a built-in /CLOSE argument is no different from having an external application do the job because calling utorrent.exe /CLOSE is exactly the same thing as calling an external application. The new instance of utorrent.exe receiving the /CLOSE argument simply passes along the /CLOSE parameter to the existing instance of utorrent.exe, and then terminates itself because µTorrent normally prevents multiple instances from being run.

@Switeck: Not being able to be terminated via external applications is a problem unto itself -- if it can't be terminated, then nothing's going to be able to force an exit, because it's obviously hung and won't respond to anything.

@ajones81: Not that this is the reason, and not that this is any technical reason, but just from a design perspective, command line arguments are supposed to be used for the instance about to be run (the instance being given the parameter initially by the user). It just so happens that µTorrent tries to handle this gracefully by passing arguments onto a running instance if /RECOVER isn't in the argument list.

It (IMO) doesn't make sense to have a commandline argument in µTorrent specifically for controlling another instance of µTorrent, and another instance of µTorrent only. Such functionality is better suited in an external application used specifically for killing processes -- like Gur Tenuis' utility. (And even if implemented, which instance of µTorrent should be given the argument? The first one? The top-most one? The one with the mutex? All of them?)

[ajones81]

I find it weird that I'm subscribed to topics here and yet never get any mails if replies have been posted. Something's wrong with the board...

Ultima, yes, that is an interesting point you make about command-line arguments. I've often thought that there should be a way to distinguish between multiple copies of uTorrent running simultaneously. For example, if the command-line args. including /RECOVER had a compulsory argument NAME so that it was specified as /RECOVER: NAME for instance, then we could solve many issues that are prevalent now. One could then, for example, execute uTorrent.exe /RECOVER: uTor1 and uTorrent.exe /RECOVER: uTor2 and have two instances run that are completely separate. uTorrent.exe /CLOSE: uTor1 would then close only the 1st instance obviously, thus solving the issue you raised.

Another advantage would be that currently, /RECOVER is a half-way measure, at best. I tried having two instances of uTorrent running simultaneously once, 'cos people here got into the bad habit of closing uTorrent and never remembering to run it again. But the problem was that though my instance, let's call it Private, ran separately with /RECOVER, the other instance (Public) would simply activate Private when run. So obviously Public needed /RECOVER too. Now the issue arose that people here press the keyboard shortcut associated with uTorrent to maximize its window from the tray. But since the shortcut had /RECOVER, every press of the keyboard shortcut ended up running a new copy! Hope you see my problem here. You see, at present there's no real way to truly run two totally separate copies of the client (I even tried one copy as a service but had the very same issues). But if a NAME param can be tagged on, that would solve everything in one go. That way I can even associate .torrents only with the Public instance, say, so that Private never pops up if .torrents are opened. What do you all think?

[Firon]

/recover is actually intended for re-opening the client after a crash. It only works for this as a side effect.

[ajones81]

Wish all side effects were as nice as this!

Seriously though, don't you think having an option to run multiple totally independant copies of uTorrent is something worth implementing? Can you at least see what the devs think of this?

Would be much appreciated.

- AJ

[Firon]

Well, we can't really do that normally for various painful reasons. :/

You -can- run multiple uTorrents with multiple users without any extra work.

[ajones81]

Well, we can't really do that normally for various painful reasons. :/

Umm, are you talking about reasons why this cannot be implemented, or reasons why you cannot see what the devs think of it?

You -can- run multiple uTorrents with multiple users without any extra work.

Any ideas you have about how to solve the problem I detailed above re. keeping Public and Private instances of uTorrent separate, I'd love to know. Is it possible with the existing version to always activate the same single running instance of Public, while also have another Private instance running hidden in the background?

Or is there some software that can encapsulate or hide an instance of uTorrent by running it in a protected address space or something, so that it cannot be seen by another instance? (Obviously not a VM or something that's plainly visible.) That would solve the issue as well, since the Public instance needn't use /RECOVER and so will not spawn a new copy every time, whereas the hidden Private instance can merrily do its job without interference or interruption..