Verify checksums in priority order instead of alphabetical order

[lex]

See 'Subject'

[jewelisheaven]

... The "Checking n.n%" procedure is in # order

Unless I missed something.

[GTHK]

I think he's speaking on a per torrent basis, checking pieces in a torrent by the priority of the files, instead of checking from the first to the last piece (which appears alphabetical).

Either that or he's basing it on bandwidth priority.

[lex]

No, I'm talking about # order.

It's not in # order now, it's in alphabetical order. I'm using 1.7.7 Build 8179.

My client is currently checking torrent #2. Torrent #1, #9, and #11 has yet to be checked. It has already checked the other numbers, in alphabetical order.

[GTHK]

That's queue order :/.

Anyway, 1.8 is going alphabetically as well.

[hermanm]

Just stop the other torrents and force recheck the one you want to download or seed first.

[lex]

It's a major inconvenience to manually work around this problem. Especially if it takes several hours to recheck everything.

Is there any reason to not follow the queue order in this case?

[jewelisheaven]

I was mistaken. The problem seems to stem from loading of the resume.dat

Because of ... protocol compatibility issues, the bencoding happens in sorted A-Z order. The Checking procedure starts at the beginning of the resume.dat. This is rather easy to verify by using Ultima's Bencoded File Editor for example moving around sub-root keys and restarting uT. You will notice the changed checking order.