0.6 Queue System

[TaperHarley]

Hi!

This is great! Just what I had in mind. I can't wait to try it

[andar]

Actually, things may be changing a bit with the queueing system in 0.6. I've been talking with Arvid, the libtorrent developer, and he is going to implement queueing inside of libtorrent so we will be using that in the future. With this change, the way queueing is handled for seeding torrents will change a bit, but I will keep you guys informed once it gets implemented in Deluge.

[TomTerrific]

So far trying out 0.6.0 the queue system is great. I find about 50% of what I used to do manually tweak is now automated.

One feature that would be a nice to have is a "per tracker" limit. One private tracker I use mandates a maximum number of torrents policy. Today I manually have to check that I don't go over it - usually by just limiting all torrents to the limit.

But a nice to have would be the ability to select "per tracker" options.

Maybe best way to handle this would be to try writing my first plug-in and see if it works - if anybody else uses it - it's a feature worth rolling into the mainline product.

A second feature was already mentioned - the ability to queue a dynamic number of torrents based on a target goal for upload / download rate.

This is maybe a even better idea for a plug-in.

I find myself manually adjusting the number of torrents seeding and downloading to use at least 80% of my target bandwidth limit.

But I also tweak the number of upload slots to use the minimum number of upload slots and still keep a decent upload bandwidth - so the faster peers can get as much bandwidth as they can use uploading from me. Better for the overall worldwide network performance to have 10 x 10 KiBs connections then 20 x 5 KiBs connections using more network overhead to maintain more connections.

[andar]

So far trying out 0.6.0 the queue system is great. I find about 50% of what I used to do manually tweak is now automated.

One feature that would be a nice to have is a "per tracker" limit. One private tracker I use mandates a maximum number of torrents policy. Today I manually have to check that I don't go over it - usually by just limiting all torrents to the limit.

But a nice to have would be the ability to select "per tracker" options.

Maybe best way to handle this would be to try writing my first plug-in and see if it works - if anybody else uses it - it's a feature worth rolling into the mainline product.

A second feature was already mentioned - the ability to queue a dynamic number of torrents based on a target goal for upload / download rate.

This is maybe a even better idea for a plug-in.

I find myself manually adjusting the number of torrents seeding and downloading to use at least 80% of my target bandwidth limit.

But I also tweak the number of upload slots to use the minimum number of upload slots and still keep a decent upload bandwidth - so the faster peers can get as much bandwidth as they can use uploading from me. Better for the overall worldwide network performance to have 10 x 10 KiBs connections then 20 x 5 KiBs connections using more network overhead to maintain more connections.

A lot of this will be implemented with the new libtorrent queuing system. It will rotate seeds based on rules such as share ratio and seed time, and should dequeue torrents when bandwidth limits are not reached.

In regards to having per-tracker options, this will likely be apart of the 'Organize' plugin. This plugin is basically a way to create custom labels with specific criteria such as trackers. You will be able to simply right-click on the label in the side bar and apply per-group settings. Extending this idea to queuing rules shouldn't be outside the scope. If you want to help with this plugin please let us know.

[fesage]

Any chance of it ever handling downloads from web browsers?

in the way that bitcomet does it for windows.

i think bitcomet is a bucket of **** (messy), deluge is clean and adding a download tab in your 0.6 for www downloads would not mess it up at all..

keep it clean

would be nice to have this option at least

[Kovensky]

I don't know if this is already on 0.6, but I like the way uTorrent handles separate queues for seeds and downloads. That way, I can download and seed without having to sort my torrents and I can maintain downloads separated from uploads.

I tried 0.6, but I broke it on the first minute. The new version is great, but I had some problems because I'm moving from uTorrent with almost 200 GB worth of torrents and deluge was having problems resuming them. It either hang while checking, or re-checked all the time, or wouldn't re-check at all, not even by forcing. I'm back using 0.5.9.1, looking forward to 0.6

[AdemoS]

Cool queue labeling system, I'm looking forward to seeing it in the main branch...

But just one thing; why are you downloading Azureus plug ins with a competing client?

[andar]

Cool queue labeling system, I'm looking forward to seeing it in the main branch...

But just one thing; why are you downloading Azureus plug ins with a competing client?

Because I abuse trackers with my constant testing.

[Drako60]

I second the complete status on torrents for the same reasons, it also helps with reseeding, a quick right click resume and its back to seeding.

One thing i would like to see is a total run time or maybe a total seed time, similar to the ETA.

[meastp]

Nice!

Perhaps an entry in preferences to prioritize torrents with size below x MB ? If you are downloading large torrents ( time > x days ), you'd want the smaller torrents (time < x hour(s) ) to gain priority and start right away, pausing the large torrents until the smaller torrents finish.