"Checking" improvements

[BZFlagLEGOManiac]

I apologize if portions of this have already been suggested, but I'm on a rant, it's late, and I'm not in the mood to go wading through 87 pages of requests (yes, I know there's a search function - I tried it and it was taking too long to read).

First my rant:

uTorrent has crashed again. I've already noticed that this has been reported many times by others so I'll download 1.8 and try again. In the mean time, I've restarted it and cringed; for I know there's a 55.1 GiggleByte torrent in there and it's going to have to be "checked".

Once again, uTorrent starts pissing me off. I love the program, but this "checking" thing drives me nuts. I could tolerate it it uTorrent didn't crash so often or if it handled itself better when it does.

Of course, my 55.1GB file is the very first thing to be "checked". That just finnished while I was searching for other feature requests on the topic, but it took 1 hour and 40 minutes to do it and this leads me to grit my teeth and bitch about uTorrent's apparent inefficiency in an otherwise excellent program.

I could have another torrent that's 99% complete and small enough to be checked in 2 minutes, but it has to wait while the gargantuine one get's checked first.

Yes, I know there's a work-around: stop the 55.1GB torrent, let the others get checked, the re-start the 55.1GB torrent. I've had to resort to this to get the almost-complete one's on their way again.

FEATURE REQUEST #1

Please put some intelligence in the "Checking..." function. Don't let one monster torrent hold the rest hostage for an hour+. Please give users the option of prioritizing the torrent checking. At the very least, have it check from smallest to largest or from most-complete to least complete. I've noticed that the order in which the files are "checked" seems to bear no relation to the number in the "#" column. I had been trying to move these large files further up or down the list so that files I wanted more urgently would get checked first but this doesn't seem to effect the checking order.

Exactly why does it take over an hour to check this file, anyway? I mean, I had just started it. It was only 1.2% complete. It only had 661MB of data.

Please tell me that uTorrent is checking the entire file. If so, though, why is it? 98.8% of the file is missing.

I shudder to think what this means if uTorrent IS checking ONLY the portion of the file that is downloaded. What would happen if the file was 98.8% COMPLETE? Does that really mean I'd be waiting 109 hours for the file to be checked, every time uTorrent crashes? That's a scary thought.

uTorrent can optionally send a crash dump when it crashes. That implies that some data regarding uTorrents operational state is being stored outside of uTorrent's memory area so that when uTorrent deep-sixes, that data is still available. That presumably being the case, could uTorrent not store data on the state of it's downloads there too, safe from a crash and available on a restart to avoid checking file segments that have already been completed? Let's see, being simplistic about it; if one stores 1 binary bit of data for each successfully saved segment and, given (if I"m reading it right) that my 55.1GB file contains 14111 segments, then a file of 1764 bytes would contain enough bits to recored which segments have already been checked. That's not an unreasonably sized file.

FEATURE REQUEST #2

Give uTorrent a way to record the state of each segment of each torrent and keep this information safe from a program crash. Reload it on program re-start and check only what has changed.

On restart, uTorrent is obviously aware that only 1.2% of my 55.1GB file was downloaded. It may not trust what was downloaded, but at least it conversly knows that 98.8% was NOT downloaded. Therefor, what is to stop uTorrent from starting to download the segments that it never had while it checks what it does have? I can understand that you wouldn't want to start uploading these existing segments until they've been verified as undamaged but it shouldn't stop you from downloading stuff you know you never had.

FEATURE REQUEST #3

Let uTorrent immediately begin downloading segments of a torrent that it had never previously downloaded, even though the previously downloaded portions of the torrent need to be checked.

[thelittlefire]

Use 1.8, and try to keep it from crashing by solving the issue. Did you have a power failure? What precipitated the loss of resume.dat?

Checking proceeds alphabetically currently, and there's a murmur that it should be changed to queue order... but that still leaves some OTHER mechanism for seeding torrents. 1.8 allows a "fast resume" as long as there is a previous session of uTorrent where the file was saved correctly.

If you have problems checking.. use the Speed tab and go to Disk Statistics and find out how fast you're checking (internal)... the external way many use here is Process Explorer because it shows disk access.

[BZFlagLEGOManiac]

Thanks. I've downloaded 1.8 now and will try it out.

As for the cause of the crashes: I simply don't know. This is the situation where uTorrent goes blank and throws up a dialogue stating that uTorrent has crashed: restart uTorrent, send a crash dump to the developers (I always do this), or abort.

There's never an explanation for the cause. The effect, of course, is that the torrents all need to be checked and that can take hours.

I'll see if 1.8 has fixed whatever the underlying cause was.

[thelittlefire]

... If you were using 1.7.5 or 1.7.6 possibly. There are remote crash exploits for the older versions. There's also some sort of UPnP crash problem in 1.7... do you have UPnP and/or NAT-PMP enabled?

As I hunted through and found earlier... the key(s) you'll be looking for in your resume.dat relating to each torrent is "resume_valid". You can use something like Ultima's Bencoded File Editor to quick-browse your resume.dat. You can find it at http://forum.utorrent.com/viewtopic.php?id=31306

[BZFlagLEGOManiac]

Thanks for the info on resume.dat.

I'll see how it performs for a week before declaring that it has resolved my problems. I am glad to see that I did not have to reboot my PC this morning so that may be a good sign.

[Firon]

1.7.7 did have some crash issues. 1.8 should be better for you.

It actually does check more intelligently on unclean shutdowns too. It checks far less files than 1.7.7 does.