Force-Recheck, follows queue order.

[Smoovious]

Ok, recently after a crash, I had to force-recheck my entire queue, and was reminded of a long-standing irritation I've had with how Force-Recheck is handled. Two, actually.

Mainly tho, it has to do with which torrents are checked first, and the consequences of the current order (which appears to be the order they are in the dat files).

If I recheck a lot of files, often times, the torrents at the top of the queue sit there, waiting to be rechecked, while torrents lower in the queue are checked. If you immediately hit the start button after starting the recheck, then you won't have any torrents go active until the top torrents in the queue have already checked, and so on.

What I propose, is that force-recheck just goes down the queue order. #1, then #2, then #3, etc etc etc... this way, when #1 is complete, and #2 starts, #1 can go active again right away, and rejoin the swarm while uT continues rechecking the other torrents further down in the queue.

I'm reminded of the other irritation tho. A while back (like, a BUNCH of versions ago), you didn't have to stop a torrent to start a recheck. Even now, you don't have to stop all of them. You only need to stop the one you right-click on. All of the other torrents that are highlighted, can still be active.

Once you start a recheck, all of the other active torrents, will stop themselves, and wait to be rechecked. So, why do we need to stop them first to begin with? This can all be handled with code.

Active torrent... click force-recheck... uT stops the torrent, sets it to recheck, rechecks it, and when complete, leaves it stopped.

I can understand leaving it stopped if it was stopped to begin with, but can we have force-recheck not have to be clicked on a stopped torrent to begin with, and then, when the recheck is complete, return the torrent to the state it was in when the recheck began?

Say, if the torrent was started, force-started, stopped, when force recheck is invoked, then, when force recheck is finished with the particular torrent, then put it back into the started, forced, or stopped status it was in before?

(I find myself constantly restarting all of the torrents, immediately after initiating the force recheck, just so they'll go active again soon as the recheck is complete. Downside is, I have to reset all of the forced torrents, granted, only 4 of them, manually... and I sometimes have to wait quite a while for all four to finish being rechecked, since I never know when they'll get their turn.)

Ok, all done with my force-recheck-related thoughts.

-- Smoovious

[thelittlefire]

This wouldn't be the first time I've heard of this one... and I do think it should be addressed at least as an option somehow for 1.9

[hermanm]

> just goes down the queue order

Are you referring to the list you see in the GUI, or torrents that are downloading?

What if I want my 100% completely torrents to force recheck first? Do just need to re-sort in the GUI?

Although it would save a step of having to click Stop, I don't see the need to press Stop to Force Recheck often.

[thelittlefire]

Rechecking proceeds in alphabetical order, aka the order of bencoding the resume.dat

[Smoovious]

What if I want my 100% completely torrents to force recheck first? Do just need to re-sort in the GUI?

Seeds, that become incomplete (which would happen during recheck temporarily) already go right to the top of the queue list.

And by queue list, I mean the # column. No matter how you sort the display, the queue order is always the # column.

Rechecking proceeds in alphabetical order, aka the order of bencoding the resume.dat

Right... the order they're in the dat file... which doesn't help the current problem. Needs to go in queue order instead. Not following the queue order, just doesn't make useful sense to me.

-- Smoovious