Opened 14 years ago

Closed 12 years ago

Last modified 12 years ago

#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)

queue_on_stalled.diff (152.2 KB) - added by Waldorf 12 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 14 years ago by livings124

  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:2 Changed 13 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 13 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 12 years ago by Waldorf

  • Milestone changed from None Set to 1.60
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Changed 12 years ago by Waldorf

comment:5 Changed 12 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 12 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 12 years ago by livings124

  • Milestone changed from 1.60 to None Set
Note: See TracTickets for help on using tickets.