Jump to content

3.3 build 29111 shutdown gives invalid download state


Dstruct

Recommended Posts

3.3 build 29111 (Windows XP SP3)

-> start

-> add some torrents to download

-> exit µTorrent

-> restart

Result: "Invalid download state, try resuming" on all files :(

I can confirm this, and add that if you have several thousand entries in the download pool, the problem is compounded even if most of the entries are inactive at the time of the shutdown.

On my system the µtorrent process fails to exit gracefully and will be running without the GUI or any visible indication at all. When I terminate the process and restart all seems well, with the exception that most of the active downloads will have to be rechecked.

If I then repeat the process of shutting down, the unchecked entries will revert to a stopped state. If I let it run its course the recheck process will eventually stall, leaving many entries at 0% checked and no way of forcing the process along.

Link to comment
Share on other sites

I wonder... Would it be feasible to have the client issue a stop for all downloads when you use File-Exit?

I don't know if you already do. although I doubt it.

Issuing a stop without changing the state so that it will resume where it left off on restart might help avoid these dirty shutdowns. It would probably take a bit longer for the shutdown to complete, but I think it could be worth it.

Link to comment
Share on other sites

It would appear that way, however the instances of this problem are not consistent, so there are other factors determining when the problem occurs. If it was just the graceful flag being ignored every single shutdown would be 'dirty'.

The two builds I have tested these last few days, 29105 and 29111, does have the problem that the process never finishes the shutdown, even after the GUI is terminated. Since the process remains (and in my case, uses some 350mb ram) I would have to say every shutdown is in fact 'dirty'.

Build 29010 didn't exhibit this as often, so I may have to revert to it and see where that leaves things.

Link to comment
Share on other sites

does have the problem that the process never finishes the shutdown, even after the GUI is terminated

The GUI does not form part of the "running processes", it is simply a configuration and control interface, and the fact that it does not complete is not in contention. It is what makes one shutdown different to others that is needing to be identified.

Obviously if you are treating uTorrent as if it were MLDonkey, then a clean shutdown will take appreciably longer than a client running as a 'casual user' operation, but finding reproducible steps to 'reliably' create the problem will assist in indentifying the code that is 'buggy' thus hasten a 'fix' being written.

Link to comment
Share on other sites

Obviously if you are treating uTorrent as if it were MLDonkey, then a clean shutdown will take appreciably longer than a client running as a 'casual user' operation, but finding reproducible steps to 'reliably' create the problem will assist in indentifying the code that is 'buggy' thus hasten a 'fix' being written.

Agreed.

It might be useful if there was a advanced setting where, when enabled, the process would log each action to a log-file, to assist with this, when simply retracing the manual steps of the user isn't helping.

Link to comment
Share on other sites

Just a thought guys, is it possible there was a lot of data in the disk write cache at shutdown? If the process eventually finishes on its own, it might be flushing the cache. IF not, it might be a bug in file i/o and it's stalled with data in the cache waiting to be written but never does.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...