Smarter logic for stalled transfers on the same tracker

[xenedar]

Request: Revision to the "Tracker is stalled" logic where, if the stalling is because of tracker non-response, other torrents using the same tracker will not be started.

More detail: I've currently queued up a number of torrents, and noticed that the first one in the list is not starting, as the tracker is not responding; it does indeed appear to be down as it's not pinging, and sites that scrape it to show the current "health" of the torrent are also unable to contact it. It's a well-known tracker, so it will no doubt come back, but I realized that T will eventually consider it a "stalled" transfer and move on. Which is good, but the problem is that the other torrents are also off the same tracker. So, over time, and depending on the value of the "no activity" preference vs the time the tracker it actually down, it is possible some or all of them will be started (as opposed to queued).

Once the tracker comes back, all of the started ones will be running simultaneously. It's always just been a fact of life that if a torrent stalls, a second is started, and the first one comes back, you will have a couple of them running, as there's no easy answer to whether to stop one, or which one. However, it occurs to me that the common factor of the tracker could help avoid this situation, particularly when the torrent itself is probably running just fine, just that the tracker is needed in the first instance to get up and running.

[livings124]

Yup, this has been on the to-do list for a bit.