Opened 11 years ago

Closed 11 years ago

#3556 closed Enhancement (wontfix)

Display as "waiting to..." when not downloading/seeding due to limit(s)

Reported by: Renara Owned by: livings124
Priority: Low Milestone: None Set
Component: Mac Client Version: 2.04
Severity: Minor Keywords: waiting to, limits, display
Cc:

Description

Doesn't condense into a title very well!

Basically when you set a limit to the maximum number of seeding or downloading torrents, the "waiting to..." state only appears for a little while, usually after un-pausing a torrent or adding a new one. The rest of the time the torrent(s) will display as downloading or seeding, whether they actually are or not.

It would be nice if when such limits are set if a torrent would return to the "waiting to..." state so it can be seen which torrents are active or have been made to wait, as otherwise the interface suggests that the limits are being ignored until you actually look in the inspector to see what's really going on.

I realise this may be a bit awkward to solve for what it adds, however I think the greater clarity and transparency of what's going on is worth it, as otherwise setting a limit on number of downloads or number of uploads visually has zero effect to the user. I'm marking this for now as a Mac OS X issue as I have no idea if this happens in the Linux/Windows? clients as well (if not then it may need to be reclassified as a bug?)

Change History (5)

comment:1 Changed 11 years ago by livings124

I'm confused by this. If a transfer says "downloading" instead of "waiting to download", it is still in the download state - it is no longer in the queue. The transfer being stalled doesn't mean it goes back to the queue.

comment:2 Changed 11 years ago by Renara

I have 12 seeding torrents at the moment, but I've set a limit of 5 torrents seeding at once, surely 7 of them should be "waiting to seed"? Even though they all appear in the seeding state, some of them clearly aren't doing anything despite available peers, I guess I just assumed that was because of the maximum setting, and that they should be "waiting to seed" if that is the case?

comment:3 Changed 11 years ago by livings124

Those transfers not doing anything are most likely in an error or stalled state, which means the queue allows other transfers to start instead of just sitting on those transfers with no activity.

comment:4 Changed 11 years ago by Renara

Ah well, in that case could these not return to the "waiting to..." state, or are you saying that if activity picked up on them again would they currently just resume (ignoring the limit)? If the latter than doesn't that go against the reason for setting a maximum?

comment:5 Changed 11 years ago by livings124

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

The queue is going to be re-written when moved to libtransmission, so instead of getting into a discussion on the merits of this, I'm going to close as a won't fix issue until the behavior for that is determined.

Note: See TracTickets for help on using tickets.