Sensible hash priority after a crash

BitComet BitComet Feature Requests
1

When BitComet crashes and gets restarted (which happens altogether too often), it should use the file size and downloaded size to determine the order in which it is going to do its hash checks on the downloads that were in progress.

As it is, if there’s one large, hairy torrent in progress, BitComet will hold up all of the others waiting for however long it takes, for that hash-check to complete. Meanwhile, all the other, much smaller tasks wait and do nothing until the huge one is complete. They could have been downloading all this time if they had been checked first.

There is no point to this waste of time. Hash checks should be done in the way that will get the most tasks actually downloading again in the shortest time.

2

Good point, utorrent does this too, and takes even longer to do the hash check from my experience.

I think if the smaller tasks were hashchecked first, it would allow the downloading to resume, then the large tasks could be hashchecked after the small ones have resumed downloading.

3

I’ve often wondered if large torrents could use something like “restore points”. for example, if every hour, the torrent would log it’s level of completion, then if somthing was to happen, instead of rehashing to determine the levels (which could take hours with a 200GB task saved on a network drive), you could just revert to a known good state, then continue from there.

You would obviously lose some progress, but could save a lot of time by avoiding the need for rehash.

Seems like it would be in the realm of possibility,anyone have an opinion?

4

How do you propose BC should go about creating a “restore point”?

The idea is not very clear to me, at this point.

I’m thinking that the purpose of the hash-check being that it verifies that whatever went wrong (crash which may have resulted in corrupted or deleted files, accidental delete, accidental rewrite by other program, accidental or intentional moving of the files, etc.) left the files intact, it would be kind of hard to detect all these things by another method.

Do you have in mind any method of creating a restore point which would detect changes such as file corruption or the lack of the actual files?

I mean, I can’t think of any other method that would let you know for sure that the file content is “still there” and what’s more, intact.

5

I like this idea.

If the team found the time to implement it, that could help a lot in many cases.

It just seems we piled a lot of suggestions on the team in the last half-year but with all this VIP/VIPA development rush, those probably have to stay somewhere lower on the priority queue.

But I, for one, certainly like the suggestion.

6

Wiz, here are my thoughts. It’s not going to be 100% perfect, but a final hash check would be needed after download is complete if this was used.

Lets say we have a 100GB torrent task and a power failure causes your computer to crash a 115am. You then restart and BitComet spends a couple hours hashchecking the task.

If it saved a restore point at 1am that listed all the pieces that were downloaded and passed hash check, then anything downloaded after 1am can be discared and download can proceed. There is a remote chance that the crash could have damaged previous pieces, but this can be checked and determined later on final hash check. Keep in mind that someone in a developing country might have a dozen or more of these crashes in the time the task is downloading, considering that this task could run for several weeks, so existing methods would do a hashcheck each time there was an error, but with a restore point, only one final rehash would be needed.

Naturally doing this could cause you to drop good data (anything downloaded from 1am till 115 when the crash occurred, but this could be a better option then stopping the download everytime a problem like this happens, but it would definitely need to be an option the user selects. Perhaps a prompt saying something like…

Corrupt data may be present and a hash check will need to be done. Would you like to hash check now, or continue download and hash check when complete?

might want to work on that language a bit

Also, depending on how much computing it would take to save a restore point, perhaps one could be made every ten mins, or even every 5 mins… at least on large torrents.

Basically it would (in effect) simply drop any data that wasn’t previously confirmed as intact.

In fact, it may not even require any special saving of a restore point. The client should already know what pieces passed hash check and it could just change the status of any previous downloaded pieces from “good” to some sort of middle ground like “unconfirmed”, so they will be kept and assumed as “good” until the final hash check is performed.

7

**Hash-check order by size **has been requested since 2011. Looks to me like this has not been considered since then. I wish to put forth this suggestion again. Why has this not been implemented in the past 3 years? It seems to me that inserting the sort routine on startup, after determining that hash-check is required, would not be that onerous.

8

I believe there was a change made where you can disable auto hash check when files changed. This is helpful if you have been saving to an external drive that was removed all the torrents will be flagged to hash check, so this feature is nice. It can also be used to let you manually do the rehashes one at a time in any order you like.

If you review the release notes over the past few years you should be able to find the changes.