Good day everyone.

In my search for the perfect torrent client for my use I have been trying KTorrent 2.2.7 for a few days now. I saw on this site that the current version is 3.1, but it requires KDE4, so I'm out of luck, as it seems to be a while till it's considered stable by the Gentoo devs.

I have tried getting as much information on features in KTorrent 3.1 from the site, this forum, the wiki-documentation and the bugzilla as possible in order to not suggest any features that have already been implemented or have previously been talked about, but I might of course have missed some. I hope that does not cause any grief.


Global transfer limits: Instead of having the two values for 'maximum downloads' and 'maximum seeds' replace the latter (or have an additional one) with 'maximum active torrents'.
This allows for more flexible scheduling of many sequential downloads that you want to switch directly from downloading to seed till they reach their designated share ratio.

Chunk bar in group tabs: A column for the group tabs showing the chunk bar like in the 'status' info widget, color-coding 'I have' and 'available in swarm' in one bar, like in many other torrent clients. This allows for a more quick overview on torrent completion than the numerical column.

Sort group tabs according to queue position: Allow the sorting of torrents in group tabs according to queue position, e.g. by having a numerical column 'queue manager/queue position' and sorting by that.
An even better way: Integrate the queue manager into the group tabs, enabling reordering of queued torrents in addition to enqueue/dequeue which is already there.

Allow disabling of peer exchange (PEX): Additionally to disabling DHT (found in 3.1 CMakeList.txt) I would like to disable peer exchange. In that context, have a further option to only accept peers listed on the tracker's reply, rejecting incoming requests/connects from IPs not seen from the tracker.
This should be an extra option per torrent, as trackers do not send every peer on large swarms.


I would like to get feedback on my ideas or your suggestions to making my suggestions even better.


Thanks for your time,

leeps

leeps wrote:Global transfer limits: Instead of having the two values for 'maximum downloads' and 'maximum seeds' replace the latter (or have an additional one) with 'maximum active torrents'.
This allows for more flexible scheduling of many sequential downloads that you want to switch directly from downloading to seed till they reach their designated share ratio.

We could do that

Chunk bar in group tabs: A column for the group tabs showing the chunk bar like in the 'status' info widget, color-coding 'I have' and 'available in swarm' in one bar, like in many other torrent clients. This allows for a more quick overview on torrent completion than the numerical column.

Sort group tabs according to queue position: Allow the sorting of torrents in group tabs according to queue position, e.g. by having a numerical column 'queue manager/queue position' and sorting by that.
An even better way: Integrate the queue manager into the group tabs, enabling reordering of queued torrents in addition to enqueue/dequeue which is already there.

Groups tab shows groups, groups don't have queue positions or chunkbars ...

Or am I misunderstanding you ?

Allow disabling of peer exchange (PEX): Additionally to disabling DHT (found in 3.1 CMakeList.txt) I would like to disable peer exchange. In that context, have a further option to only accept peers listed on the tracker's reply, rejecting incoming requests/connects from IPs not seen from the tracker.
This should be an extra option per torrent, as trackers do not send every peer on large swarms.

PEX can be disabled per torrent, but not globally (which we could add). I see no reason why you want to disable this at compile time, the only reason why we added this for DHT, was SUSE being scared by a bunch of lawyers.

I also see no reason why we should only accept peers on the tracker list, seeing that the swarm can be much bigger then what the tracker returns, you would be limiting yourself for no reason at all. Further more even if the tracker gives you the full list, you will not be able to connect to new peers which announce after you, further limiting yourself.

Thank you for your reply, George.

George wrote:

leeps wrote:Chunk bar in group tabs [...]
Sort group tabs according to queue position [...]

Groups tab shows groups, groups don't have queue positions or chunkbars ...

While this is certainly true, I was trying to be able to emulate what other torrent clients can do in their 'main view'. I'd personally like to think of groups as 'filters' (which seems to be exactly what they are), and then it mainly comes down to displaying more information on the unfiltered torrent list. Columns are selectable, so only those who want this information can enable it. I see no harm done to usability or conceptual design.

George wrote:

leeps wrote:Allow disabling of peer exchange (PEX) [...]
This should be an extra option per torrent, as trackers do not send every peer on large swarms.

PEX can be disabled per torrent, but not globally (which we could add). I see no reason why you want to disable this at compile time, the only reason why we added this for DHT, was SUSE being scared by a bunch of lawyers.

I had assumed you had made the decision to allow disabling DHT at compile time due to other reasons. Of course one would not need to disable PEX at compile time if one doesn't care if it is included in the resulting binary. I apologize for the bad wording of my suggestion.

George wrote:I also see no reason why we should only accept peers on the tracker list, seeing that the swarm can be much bigger then what the tracker returns, you would be limiting yourself for no reason at all. Further more even if the tracker gives you the full list, you will not be able to connect to new peers which announce after you, further limiting yourself.

Hm, it seems any new peer will not be recognized by all others till those refresh. On large swarms, if the tracker randomly selects the peers it sends, it might take some time till new peers are allowed to connect anywhere they are known. This is something I admit not having thought about when proposing this. I am thankful you pointed that out to me!
While this could still be done selectively, the need for this feature has been diminished.


Thank you for your response on my suggestions. After watching ktorrent over the weekend I've come to really like it, and look forward to finally using version 3 after KDE4 gets stable in Gentoo. If you take suggestions on priority, the most wanted feature would be the global transfer limits as outlined in my first post :)

With the best wishes,

leeps