I received a warning for cheating on one major tracker. The problem is that I only downloaded one file of a big torrent. After the file was downloaded, the tracker register me as a seeder instead of a leecher. The admins flagged me as a cheater, since it was not possible to complete the download in the short amount of time I did.

I told the admins why it happened, and they where happy for being enlightened about this behaviour in Ktorrent, which according to them, where different from other clients, which will still be in "leeching" mode after all files you select are downloaded, as long as not all the files in the torrent have been selected.

Is this the way Ktorrent is supposed to work, or is there any plan on changing this?

EDIT: v2.0.2

If I'm not mistaken this is already fixed and there will be a new release very soon (the next couple of days) which will include this fix, so stop by here for an announcement or visit our website to grab new version.

BTW, just from curiosity, which tracker are you talking about?

Ivan,

if this is fixed in SVN, can you please locate the revision for me where this is fixed, or provide a patch against 2.0.2 if that SVN diff won't apply cleanly?

At this point in the Ubuntu Edgy development cycle (deep freeze is the best way to describe it, ESPECIALLY since KTorrent has become a core part of the Kubuntu desktop), it is much easier for me to get patches/backported fixes accepted in rather than an entirely new upstream version.

Well, you should probably talk with George about that one. When we were talking about backporting that patch for 2.0.3 he said it won't be so easy and it took him some time to make this backport work good.

But I guess you could extract patches from branches directory in SVN where 2.0.3 development is in progress. Actually, it's 2.0.2 with all applied patches. It would be great if you could use 2.0.3 this weekend but I don't know if that makes you troubles (edgy dev. cycle you mentioned)...

Thank you so much! I really enjoy this client, and the developers. The tracker mentioned was http://hdbits.org

Ivan wrote:Well, you should probably talk with George about that one. When we were talking about backporting that patch for 2.0.3 he said it won't be so easy and it took him some time to make this backport work good.

But I guess you could extract patches from branches directory in SVN where 2.0.3 development is in progress. Actually, it's 2.0.2 with all applied patches. It would be great if you could use 2.0.3 this weekend but I don't know if that makes you troubles (edgy dev. cycle you mentioned)...

mmmkay, I'll try to get 2.0.3 approved then.

P.S. I don't meant to rant or criticize or anything, but for these kind of point releases, could you guys please furnish a half-decent changelog? It needs to be more specific than the half-sentence "fixed download corruption" that you guys typically give. One part of the procedure for this kind of exception is an acceptable changelog, and the past few times I had to dig through SVN, and read per-revision diffs (as the SVN changelog is also pretty vague and not useful for convincing the supers). That would make introducing 2.0.3 a lot easier.

jdong wrote:P.S. I don't meant to rant or criticize or anything, but for these kind of point releases, could you guys please furnish a half-decent changelog? It needs to be more specific than the half-sentence "fixed download corruption" that you guys typically give. One part of the procedure for this kind of exception is an acceptable changelog, and the past few times I had to dig through SVN, and read per-revision diffs (as the SVN changelog is also pretty vague and not useful for convincing the supers). That would make introducing 2.0.3 a lot easier.

Your criticism is valid, the problem is that I tend to forget maintaining the Changelog, because I don't like doing this kind of 'paperwork'.

I guess it wouldn't hurt to elaborate a bit more about bug fixes in commit messages.