Alternate upload rate in seeding only mode.

Has this been requested before?

Alternate upload rate when not downloading only seems to work when there's no torrent listed as downloading in the status field. This looks to have been designed to kick in when a torrent has finished downloading and you're not there to change the upload rate. You should be able to do the same when seeding only mode kicks in. It's wasted upload time if you only have a 256kb upload connection.

... First tell me that the alternative upload rate doesn't work in seed-only mode.

No it doesn't. I've tried on numerous occasions to get it to work. I've also just noticed that it doesn't work if you pause all downloading torrents. The only time it works is when all torrents are listed as seeding in the status field.

Seeding only mode doesn't change the status, i.e. from downloading to seeding.

I can neither confirm nor deny confirm both of your behaviours.

As far as alternate upload rate not kicking in on Seed-Only Scheduler times, maybe that's by design, maybe not.

However for pausing downloads = not uploading, no duh? If it is downloading, and it is paused, you expect it to register "only uploading"... You have active non-seeding torrents. Cognitive dissonance ensues.

By pausing, I should have said it doesn't kick in if you have a paused torrent (I was pausing one to test). It was just to show that alternate upload rate doesn't work unless all torrents are listed as seeding. Not sure if stopped counts, but that works as well.

Thanks for taking the time to check it out.

The alternate upload rate always kicks in during limited mode, regardless of what the torrent statuses are. The alternate upload rate never kicks in during seeding only mode. Whether it should, I don't know; some users might say it should, but I'm certain others wouldn't want it either.

There is no alternate upload rate for seeding in limited mode of the Scheduler. The SCHEDULER limits are applied during the "limited" blocks. Neither peterdiva nor I was talking about LIMITED mode Thanks for your verification Ultima.

Yah, I understood that bit; I was outlining clearly when something does and doesn't happen. Basically, what I was saying was that it doesn't depend on when a torrent is of some status or other.

Yup Yup!! Perhaps more discussion is warranted about the global alternate upload limit being applicable/not applicable to seed-only mode? Thanks Ultima, your re-write of the manual looks great from here (the parts you've posted already).

Perhaps more discussion is warranted about the global alternate upload limit being applicable/not applicable to seed-only mode?

Maybe... It could just as easily be added as another option, but I doubt that'll happen. Firon has already said that the scheduler would be overhauled in 1.9, and it's something I'm looking forward to as well, because although the current scheduler system has served us well, I felt that it was just a bit too limiting.

That's funny because when Firon said that for 1.9 I was saying to myself "and what can they possibly add to it" I'm surprised noone has put out fanfare that the Seeding Only mode was added to the Scheduler pane in the recent 1.8 builds. I am very pleased with the progression of features / UI development.. I'm content since I didn't have to wait for 1.9 to turn off those stupid blocked peer messages :D

It took a bit of bugging from Firon and I to get Ryan to remember to make the scheduler changes ;D

I've been maintaining a list of interface quirks/suggestions for Ryan for over a month now, and he's fixed around 20 of them now. I've still got about 15-20 more on the list for him to pick off at his leisure. (BTW, using LVM_ENSUREVISIBLE to keep an item visible when getting moved up/down the queue is also already on my list, so Ryan should see it sooner or later if he doesn't notice that thread on his own)

A rules-based scheduler would be a lot more powerful than the current scheduler, and that's what I have in mind to push to the devs should the opportunity ever present itself for me to do so

The scheduler revamp is on the todo, but it's set for the 1.9 milestone.

If they plan on implementing per-label options, I'd think that should prioritize over any "rules" scheme available now or in the future. If you have that, then "rules" become moot. Additionally, I'm not sure whether or not adding functionality while removing the current grid is all that useful. Generally speaking, 2(3) rates-of-speed is plenty of customization along with the OFF functionality

Er, per-label options doesn't really have much to do with the scheduler. The scheduler is timed, per-label options aren't, so one wouldn't make the other pointless -- they augment each other. Whether one should override the other is a fair question, but I'm sure it'll come up as part of the redesign plans.

The grid is pretty, but it's difficult/annoying to use. Every time I want to select a time, I have to mouse over each box on the day of the week until see the right time. Wouldn't it be easier to just select the day of the week from a list, and type in the time of day?

Also a fair point. It completely depends upon how much of the current featureset is allowed to be set per-label. My point about the grid is it's intuitive and picture-like. Sure a drop-down is cooler, and takes up less space which allows for more data to be crammed into the pane, but again I think my limitation on imagining it any different is finding any deficiency or lack of utility in the current implementation.

You can't set more than one speed limit, so all Limited periods MUST run at the same speed. What if you wanted on block of time to be a certain speed, and another block of time to be another? What about if you want to set specific speeds at specific times depending on the label? None of those are possible with the current implementation.

That aside, the table just takes up so much space, so there's hardly any room for actually putting more options.

"What about if you want to set specific speeds at specific times depending on the label?" Precisely my point, about implementing some sort of scheduler with the per-label options.

Splitting it into the label options doesn't sound like a good design to me. The scheduler needs to be in one centralized location, otherwise it's near-impossible to manage your schedule coherently :| A schedule is supposed to be used as a single location to check what you do at specific times. If you have class (in school), you don't put your class start/end times on each notebook you have for each class (hypothetical situation: assume you do use one notebook per class); you keep the scheduler all in one location. Same idea here.