I want to suggest a new feature for ktorrent.
It is implementation of Tracker 'scrape' Convention
You can find it here:
http://wiki.theory.org/BitTorrentSpecification

Using this protocol is possible for a torrent client to receive statistic information about a torrent file. This information should be usefull for seeding queue manager. Using this protocol can be received the number of seeder/leacher for a torrent, so ktorrent can implement different seeding algorithms.

For example if the number of seeders for a torrent become 0, the queue manager cant start seeding of the torrent immediately (if the number of leachers is > 0). Also, if the number of leachers is 0, there is no need of seeding, so ktorrent can start seeding another torrent with more leachers. This is a feature that I noticed in azuerus and will be great if it is available in ktorrent.

Furthermore the peer info can be more detailed. For eample, now ktorrent display seeder/leachers number as: 10 (20) where the first numer is the number of connect peers and the second numer is number of available peers. But number of available peers isn't very correct. It is the number of peers received from the tracker, but no more than 100, as the "numwant" parameter used as a query to the tracker is 100. I suggest to be used this protocol to be detected the total number of available peers.

Just one more issue.
In the "Uploads" page in the "Status" the number of seeder is always 0 (0). It will be great if the number of seeders is displayed, so I whould know which torrent needs more upload, to start it manual. For example 0 (20) or 0 (1). I think, the total number of the seeders/leachers should be always in the brackets for the torrents maintained by the queue manager.

This is surely a good idea. Very usefull indeed.

For eample, now ktorrent display seeder/leachers number as: 10 (20) where the first numer is the number of connect peers and the second numer is number of available peers. But number of available peers isn't very correct. It is the number of peers received from the tracker, but no more than 100, as the "numwant" parameter used as a query to the tracker is 100

I think that either trackers respond differently or KT has some problem parsing the information. Some trackers make KT show correct info like, for example, 20(5000) seeders. 5000 is lot more than 'numwant' so KT is receiving good info here. With other trackers, KT shows number of available peers according to the number of successfull connections like - 20(20). As other peers connect so do the numbers increase.

Nevertheless, scrapping will surely help with this 'problem'.

Some trackers make KT show correct info like, for example, 20(5000) seeders. 5000 is lot more than 'numwant' so KT is receiving good info here. With other trackers, KT shows number of available peers according to the number of successfull connections like - 20(20).

This is because some trackers doesn't return "complete" and "incomplete" keys in their response.

Nikolay wrote:This is because some trackers doesn't return "complete" and "incomplete" keys in their response.

that's right, but in the case of ktorrent, it doesn't show scrape info even in cases where other bittorrent clients do.

anyway, i'm very, very happy to see a fast native kde bittorrent client. azureus has become unbearable lately (swt+gtk is sooo broken) and python is not the right way to go. thanks joris & ivan (and all the other contributors)!
if it could support scraping too, it'd be fantastic. the imo other two most important extended features (azureus subslices and dht) are already there, so...

Nikolay wrote:

Some trackers make KT show correct info like, for example, 20(5000) seeders. 5000 is lot more than 'numwant' so KT is receiving good info here. With other trackers, KT shows number of available peers according to the number of successfull connections like - 20(20).

This is because some trackers doesn't return "complete" and "incomplete" keys in their response.

Indeed, some don't do this and then we just use the total number of peers.

I was gonna do scrape at one time, but then other things got in the way. Looks like our TODO list is getting longer.