Last night when I had sleeping problem I made some changes in chunkselector.cpp to get KTorrent to select chunks in a better way, selecting rarest chunks first .

Today I have KTorrent running, with better selection, and some better speed - more peers are connecting to me.

I will send my changes when I found why the KTorrent now start with allocating the whole file when starting up - freezing the application for 30-40 sec. (And clean upp code + add some comments).

Pär H

KT at the start creates an empty file and only expands it when needed, so that shouldn't happen.

That was my post.

If your rarest chunk first algorithm selects a chunk at the end of the file, you will have huge writes to disk, which could cause this behavior. To counter this we have a slowly increasing limit, that way the disk writes stay small.

I have located the reason.

The torrent i tested had 2 files
1 ISO-file of 3GB, and 1 AVI-file of 20KB. The AVI-file got priority (ChunkSelector::findPriorityChunk), and when the AVI-file was located at the end of the torrent the large file got allocated.

Another torrent i tested started allocating at the end because one peer had only a few (0,02%) chunks, and those where near the end.
---------------
Regarding chunkselector .cpp / .h, Can I mail the files?

Sure send them.

Maybe we need to switch to a temp file, basicly if the chunk is within the limit, write to the final file, if not write to tmpfile. And if the limit moves up see if we can write some chunks from tmpfile to final. But that could cause problems with the preview of multimedia files ...