We are planning to implement queue manager for torrents and we'd like to hear your opinion. We have two options:

1. Add another column to TorrentView where you can select torrent priority (from very_low to very_high) and when current download is finished KT automatically selects torrent with greatest priority and starts download. In this case, if there are two or more torrents with the same priority KT will choose the first it finds.

2. Add queue dialog and allow the user to modify the queue (a simple dialog with a move up and down button, and maybe something to edit the number of concurrent uploads). When the user then loads a new one we move that torrent to the end of the queue.

Please, respond to this poll ASAP since we need to start working on this so it can be finished before Christmas.

Option one sounds like a more powerful method. Perhaps a limit could be set in the KTorrent config to limit the number of concurrent torrents. KTorrent could then use the priority system to decide which torrents to download.

In addition, maybe KTorrent would give top priority to the smallest downloads? Or perhaps the one with the best average speed?

Option one sounds like a more powerful method. Perhaps a limit could be set in the KTorrent config to limit the number of concurrent torrents. KTorrent could then use the priority system to decide which torrents to download.

We already have this option in settings All we need now is priority system.

Priority setting is probably the only feature I miss by using Ktorrent.

I like the idea about priority system and my vote is for it.

I prefer option 2.

Option 2 is more powerful, becuse it gives unique priority to every torrent.

If we're talking about entire torrents, i like the sound of option 2...

...But what i'm really yearning for is the ability to prioritise individual files within torrents, as i used to do with bittornado before dumping Gnome & GTK in favour of KDE & QT (& i don't consider Azureus to be an option).

A queue (option 2) with an absolute order is the way to go.
Being able to have 2 resources with the same priority isn't a feature.

Also I'm not sure that specifying the priorities in a separate dialog is really handy.
All the clients allowing multiple downloads that I know (azureus, ABC, G3, rufus) allow you to reorder the queue from the main window ( 2 arrows on a toolbar, it's not that much. People will only say kde apps look bloated if you also put move-to-first and move-to-last buttons like in azureus :-)

Ivan wrote:

Option one sounds like a more powerful method. Perhaps a limit could be set in the KTorrent config to limit the number of concurrent torrents. KTorrent could then use the priority system to decide which torrents to download.

We already have this option in settings ;) All we need now is priority system.

Is there a reason a config value shouldn't be set from more than one place ?
If you have a manage-this-queue-of-elements window it seems logical to be able to change the number of elements treated as well as the order they will be treated.

Also I'm not sure that specifying the priorities in a separate dialog is really handy.
All the clients allowing multiple downloads that I know (azureus, ABC, G3, rufus) allow you to reorder the queue from the main window

I agree with you and personally I prefer this. But, I'm sure there are people that would like to sort main window downloads in their own way - not by priorities, so that wouldn't work.

Is there a reason a config value shouldn't be set from more than one place ?

No, not really. But, if you look a bit closer you'll see that Devari (Guest) said:

Perhaps a limit could be set in the KTorrent config to limit ...

... and this had nothing to do with 'option2' dialog since he prefers the other option. So I just answered that we already have the limit option.

Offcourse, I don't mind having this option in queue dialog too.

Ivan wrote:But, I'm sure there are people that would like to sort main window downloads in their own way - not by priorities, so that wouldn't work.

I see what you mean.

So the question is more "are priorities managed in the main window with a new column to keep track or is this done in a separate dialog ?".
I don't have a very strong opinion about it but :
- if you go with a separate dialog people will ask you for a way to know wich torrent is next. So you'll probably end up with a queue-order / priority column in the end anyway.
- once you have a new window you are eager to fill it with all sort of insightfull stuff. It won't take long before people ask guards (nbSeeder / nbLeecher > 5 && nbSeeder > 20) and before you know it you are embedding a scripting language in your app...

But, if you look a bit closer you'll see that Devari (Guest) said:

Perhaps a limit could be set in the KTorrent config to limit ...

... and this had nothing to do with 'option2' dialog since he prefers the other option.

My bad I misread.

I like the second option. But what I miss is the option to say that once a ratio is reached stop seeding. I don't mean to suggest that things should be done like other programs but it seems azureus and ABC have pretty good systems.

For instance... I have a set of files that I downloaded and there are not proper sedders because only every couple of days someone will decide to download that show. So in azureus I have set it so that I only have 6 transfers going at one time. But no more than 4 can be downloading. This way 2 will always be seeding. But after the downloads are done they must wait until it has seeded to a 1:1 ratio. This way the downloads are properly seeded before they start new downloads. Now priority of seeds are based on how many seeders to the number of peers. A file with one peer and no seeders will be put ahead of a file with 1 seeder to 3 peers. This I believe helps the swarm.

As far as download priority..... just make it list downloads by number and what ever is in the number one slot gets downloaded first. Its the easiest way to do it. But you would have to seperate your seeds from dls.

But what I miss is the option to say that once a ratio is reached stop seeding

It is planned to do. I'm not really sure it'll be available in final 1.2, though.

Another vote for Queue dialog (option 2) because it can be more powerfull.

I vote option 1 (Queue manager in Azureus style): very easy to set/view.