I have noticed a tendancy for the recently added chunks "Left" box in the infowidget to show a _really_ big number - _far_ more than there are chunks in the torrent. My guess would be that's an unsigned number that went below 0, so it went around to a really high positive number.

I've only seen this on torrents where I've unselected files for download. However, it's not as as simple as "the number is wrong if files are unselected for download." There are torrents where I have unselected files and the number of chunks left is correct. I think that it is happening only in cases where files are unselected for download _after_ they have already been partially downloaded. I do this all the time in an attempt to force KTorrent to download a specific file first when it appears to be favoring others in spite of them being marked as "Download Last" and the one I want first being marked as "Download First". In any case, if all the files are reselected for the download, the number of chunks left is correct at that point.

I think that when it's doing the calculation for chunks left it's simply subtracting the number of chunks download from the total number of chunks. Because the number of chunks downloaded includes chunks that have already been downloaded but now are not selected to be downloaded and thus are not counted as part of the "Total" number of chunks, the chunks downloaded exceeds the total number of chunks and then when the result is below 0 in an unsigned integer it becomes a really _big_ number.

This is similar to how the number of MB downloaded can be far larger than the size of the torrent (in the main display) when you unselect files that have been partially downloaded. Of course in that case, no math is done and the number of MB downloaded hasn't changed even if some of it is no longer selected to be downloaded, so it is probably perfectly reasonably - if odd - to allow it to display that it has downloaded more than MB than the size of the torrent.

To make matters more interesting, it would appear that in order to correct the math for the chunks left, you would have to know how many chunks have been downloaded that are currently selected for download instead of simply taking the number of downloaded chunks which is probably just an integer somewhere that gets incremented as chunks get downloaded. I don't know anything about the code, so I can't say how easy it would be to categorize chunks efficiently, but making the "Left" box display correctly will likely require quite a bit more work than the simple arithmetic that appears to be done at the moment.

In any case, I thought that I should point the bug out. Oh, and I'm using the 2007-04-28 SVN snapshot in case this was actually found and fixed since then.

P.S. A quick and easy way to see this bug for yourself is to unselect a file in a multi-file seeding torrent.

Fixed, the calculation was wrong, but we were already calculating it correctly somewhere else, so we now just use that value and the problem is gone.

Well, that was simple then. I was afraid that the fix was going to be overly complex. Thanks!