It seems like my last set of feature requests yesterday disappeared magically today (some forum troubles, perhaps?), so I'll post them again in case they got lost:

(1) Ability to add a torrent without starting it automatically.
(2) Ability to scrape trackers/dht on stopped torrents, so I can estimate the torrent's health without starting it.
(3) A PEX tickbox column, and/or displaying how many peers were found through PEX
(4) Accurate swarm size indication, factoring in PEX and DHT rather than just tracker.

Oh, them culprits ate my full disk allocation request as well!

Now that I have some more time, maybe I'll be able to sit down on C++/Qt a bit and in one year time I won't have to request anything anymore, khkhkh. Ingenious plan.

Full disk allocation is planned, so that should make it into 2.2.

(1) Ability to add a torrent without starting it automatically.

Why is this necessary ? If you don't want to start it just yet, you can just not add it.

(2) Ability to scrape trackers/dht on stopped torrents, so I can estimate the torrent's health without starting it.

Interesting, we could add an option to do this on the right click menu, which scrapes the torrent and starts looking around on DHT. To get some indication on the number of peers.

(3) A PEX tickbox column, and/or displaying how many peers were found through PEX

Tickbox shouldn't be a problem, how many peers is not so simple.

(4) Accurate swarm size indication, factoring in PEX and DHT rather than just tracker.

PEX is not a good way to estimate the swarm size. DHT has also it's drawbacks, the problem is that if you find a potential peer with DHT, you cannot know for sure that a tracker does not know this peer, so this could easily lead to estimates which are larger then the swarm.

George wrote:Full disk allocation is planned, so that should make it into 2.2.

(1) Ability to add a torrent without starting it automatically.

Why is this necessary ? If you don't want to start it just yet, you can just not add it.

Sometimes I'd just like to have 10 torrents loaded into KTorrent of stuff I'd like to download in the near future, but not exactly right now. Anyway, that's just a silly little request . If it takes any effort to implement it, then forget it.

(4) Accurate swarm size indication, factoring in PEX and DHT rather than just tracker.

PEX is not a good way to estimate the swarm size. DHT has also it's drawbacks, the problem is that if you find a potential peer with DHT, you cannot know for sure that a tracker does not know this peer, so this could easily lead to estimates which are larger then the swarm.

Can we have some sort of class that would manage all the peers that PeerSources emits and filters to only unique ones? Azureus and uTorrent both report unique peers received through their distributed tracking system. With that, PEX results can be more useful too. Perhaps such a system can also help out with performance too as we don't waste time trying to always reconnect to people we've already tried connecting to several times?

(1) Ability to add a torrent without starting it automatically.

If you wanted to be able to do this from the command line, I believe you could adapt the ktshell script to start up the new torrent then stop it right away. Would that be close enough to what you want?

J. Frank Parnell wrote:

(1) Ability to add a torrent without starting it automatically.

If you wanted to be able to do this from the command line, I believe you could adapt the ktshell script to start up the new torrent then stop it right away. Would that be close enough to what you want?

No, on some networks I'm on I would not like any torrent traffic leaking out from my computer at all, lest it be cause for a permanent ban and administrative action. Anal? yes, most certainly.

Can we have some sort of class that would manage all the peers that PeerSources emits and filters to only unique ones? Azureus and uTorrent both report unique peers received through their distributed tracking system. With that, PEX results can be more useful too. Perhaps such a system can also help out with performance too as we don't waste time trying to always reconnect to people we've already tried connecting to several times?

I have noticed that the inclusion of PEX creates a lot of additional connection attempts, so I'm allready looking at removing IP and port combinations we are allready connected to.

George wrote:I have noticed that the inclusion of PEX creates a lot of additional connection attempts, so I'm allready looking at removing IP and port combinations we are allready connected to.

The more pressing problem at least in my mind is reconnecting to dead peers again and again. If a connection is attempted to a reachable peer, the operation is quite fast.

But connecting to unreachable IP's and timing-out peers is time-consuming and really ties up half-open connection resources at the network gateway.

So, some way of rate-limiting how long before re-attempting such peers would be ideal too, though these really sound complicating to me.

jdong wrote:

George wrote:Full disk allocation is planned, so that should make it into 2.2.

(1) Ability to add a torrent without starting it automatically.

Why is this necessary ? If you don't want to start it just yet, you can just not add it.

Sometimes I'd just like to have 10 torrents loaded into KTorrent of stuff I'd like to download in the near future, but not exactly right now. Anyway, that's just a silly little request . If it takes any effort to implement it, then forget it.

I'd use it happens to be useful several times (I'm just too quick with the stop toolbar button:))

and one wish in the wish-topic:

I'd like to have column with idle time, i.e. how many hours (for example) torrents are inactive (no download/upload traffic).

You guys should now that we intend to start the port to KDE4 after 2.1, So 2.2 will be parallel developed with 3.0, so the time we have will be split between both development efforts.