th0th wrote:Mine was a multi-file download on both occasions.

Where they also with a small last file ?

Here's another interesting phenomenon: sort by completion percentage, and you'll find that some of the 99.90% ones sort below the 100% ones.

George, what to do to debug this? I have 99,90% complete again. Of course, I can restart KTorrent as it usually helps. I have one chunk left not downloaded, many alive peers (not choked & not snubbed) and no assigned chunks. There are 61 seeders and 40 leechers for that torrent. It's multifile torrent, all files in one directory thou.

jabbervorx wrote:George, what to do to debug this? I have 99,90% complete again. Of course, I can restart KTorrent as it usually helps. I have one chunk left not downloaded, many alive peers (not choked & not snubbed) and no assigned chunks. There are 61 seeders and 40 leechers for that torrent. It's multifile torrent, all files in one directory thou.

One more thing I noticed: ktorrent eats 47% of cpu, not 5-10% as usual. Tracker says I have no down traffic right now, but I have up traffic.

I got another stalled:
- 99.72%
- 352 chucks@ 1MB
- downloaded chucks 351

- torrentsize 351.3 MB
- downloaded 351.3 MB (which can't be off course)

- no chucks assigned
- single avi file

I'll let KTorrent run in this state until 22:00
EDIT
Okey, that failed. (KDE or Kwin crashed on me)

stoeptegel wrote:I got another stalled:
- 99.72%
- 352 chucks@ 1MB
- downloaded chucks 351

- torrentsize 351.3 MB
- downloaded 351.3 MB (which can't be off course)

There allways the possibility that pieces can be downloaded twice, when there are more then one peers assigned to a chunk. Which usually results in somewhat more data downloaded then there should be (but we cap bytes downloaded on the size of the file)

- no chucks assigned
- single avi file

I'll let KTorrent run in this state until 22:00
EDIT
Okey, that failed. (KDE or Kwin crashed on me)

Which leads me to believe that the problem is in the chunk selection, I'm gonna rewrite the selection algorithm (making it more efficient at the same time)

George wrote:There allways the possibility that pieces can be downloaded twice, when there are more then one peers assigned to a chunk. Which usually results in somewhat more data downloaded then there should be (but we cap bytes downloaded on the size of the file)

Ah so this also takes all the discarded pieces into account, that logic. Dunno why the %@#% i didn't see this.
What about a counter in the chunks table that counts the discarded chucks seperately? (or should this be on pieces level to be more exact)

Which leads me to believe that the problem is in the chunk selection, I'm gonna rewrite the selection algorithm (making it more efficient at the same time)

whoeyah!

I too am having this same problem, stopped at 99.90%. I am using 1.2 and it is a multi part file. However, all of the files downloaded execpt the largest one several days ago. I have tried the start and stop method and have also tried the restarting ktorrent method. I noticed when doing the later that each time it restarts it redownloads the same chunk (in this case chunk 320). I would mark it up as the part simply not being available except I usually have between 300-400 peers on this file. The files stats are Leechers 205(2385) Seeders 22(564). I would think that at least one of those people has the chunk that I am missing.

Allright, chunk selection has been redone, at the same time I have added preallocation. So when you start a new download, the diskspace required will be reserved and during the download it will be filled up. This can take some time if you have multi gigabyte files. But that is just the first time you load the torrent.

Lets hope this gets rid of the 99.9 % stalled problem.

George wrote:Lets hope this gets rid of the 99.9 % stalled problem.

It compiled smoothly, and 4 torrents were completed today with the new version (but as I encountered the 99.90 problem about once a week that's no proof yet...)

jyhelle wrote:(but as I encountered the 99.90 problem about once a week that's no proof yet...)

I also concluded that it was a rare popping up bug(but a nasty one), but we'll see it eventually if it's gone.

I hate bringing bad news... but this morning I had a stalled torrent (single file, 1244 chunks, 1242 loaded, 0 active with 26 seeders among which 12 in the "not choked-not snubbed" state)

Stopped and restarted KT and the torrent completed in seconds, but it revealed an added "feature"
when restarting I had to accept dozens of error messages stating that I could only have 10 active torrents, bla bla bla. It seems KT now tries to start all torrents in the waiting list and not only those that were active when last quitted...

I hate bringing bad news... but this morning I had a stalled torrent (single file, 1244 chunks, 1242 loaded, 0 active with 26 seeders among which 12 in the "not choked-not snubbed" state)

Damn, then it isn't in the chunk selection ... , we will have to examine it further

Stopped and restarted KT and the torrent completed in seconds, but it revealed an added "feature" Wink
when restarting I had to accept dozens of error messages stating that I could only have 10 active torrents, bla bla bla. It seems KT now tries to start all torrents in the waiting list and not only those that were active when last quitted...

Normally it should remember this, Ivan will have to take a look at it.

Does this happen again when you restart it again ?

George wrote:Does this happen again when you restart it again ?

yes, the numbers are right: 43 torrents in the list with the active limit set at 10 and I counted 33 error pop-ups to close

the order is OK, though, as the 10 that are eventually running are the 10 that were active before quitting

I noticed that recently. I'm working on a fix.