#364 closed Enhancement (wontfix)
Stalled torrents not queued, but left to linger and become active once again
| Reported by: | tiennou | Owned by: | livings124 |
|---|---|---|---|
| Priority: | Normal | Milestone: | None Set |
| Component: | Mac Client | Version: | 0.82 |
| Severity: | Normal | Keywords: | |
| Cc: |
Description
When a torrent stalls, T start the next torrent in queue after the time set in prefs passes, but it doesn't stop (eg. requeue) the torrent that was stalled, meaning that the max download active pref is not honored... I guess that if you have more than one torrent stallin you would get all your torrent running at the same time at the end...
Attachments (1)
Change History (8)
comment:1 Changed 15 years ago by livings124
- Resolution set to wontfix
- Status changed from new to closed
comment:2 Changed 15 years ago by Waldorf
- Resolution wontfix deleted
- Status changed from closed to reopened
- Summary changed from Stalled torrent not stopped after delay to Stalled torrents not queued, but left to linger and become active once again
- Type changed from Bug to Enhancement
- Version changed from 0.82+ to 1.06
With the recent talk about #726 made me remember this old ticket.
I noticed (then) that others are having the same issue as I have. I have a lot of stalled torrents that come to live every few hours/days. I'm not sure wether there actually was such a thing as 'inactive torrent' back in 0.82, but there is now. So now the logic is there, how about queueing those inactive ones?
comment:3 Changed 15 years ago by livings124
- Resolution set to wontfix
- Status changed from reopened to closed
- Version changed from 1.06 to 0.82
Nothing has changed....
comment:4 Changed 14 years ago by Waldorf
- Milestone changed from None Set to 1.60
- Resolution wontfix deleted
- Status changed from closed to reopened
Changed 14 years ago by Waldorf
comment:5 Changed 14 years ago by Waldorf
[PATCH]: If you're wondering why some checks/calls were removed, it's either because I thought they were redundant or (as in updateTorrentsInQueue) were causing issues.
comment:6 Changed 14 years ago by livings124
- Resolution set to wontfix
- Status changed from reopened to closed
Quite honestly, I do not want to mess with the queue code - it is being moved to libtransmission in a future release. The queue is currently very fickle, with a lot of edge cases that have to be watched for. I'm afraid that this patch does not account for all possible cases.
comment:7 Changed 14 years ago by livings124
- Milestone changed from 1.60 to None Set
This has been discussed A LOT and the conclusion was there was no elegant way to have proper behavior with the queue and stalled torrents in this regard, since pausing stalled torrents when they unstall makes no sense. The best bet is to just leave stalled torrents, since the chance of them unstalling isn't all too high. Stopping a stalled torrent also doesn't make sense, because if they all stall all of a sudden you just keep on iterating through stalled torrents, and if one that is waiting to enter the queue does unstall, it will have to wait for the other stalled one. It just becomes a lot of complicated logic with no good solution, so the best bet is to just let stalled and error'ed torrents exist outside the queue.