I'm gonna try that download with SVN HEAD too.

jdong wrote:I'm gonna try that download with SVN HEAD too.

Caught! I spotted you in swarm

stoeptegel wrote:+1
I download the full torrent and got no problems with data.
Are you sure you don't have parts of both versions on your system?

The said messages appeared using 2.0.3 so consecutively I tried the snapshot. Anyways, seems the problem is on my side. I'll further investigate and report back if I'll find anything - maybe my harddisk poses problems, who knows.
Quick question: May it be that certain kinds of filesystems can pose problems? I mean, regarding the preallocation of diskspace for downloaded files?!?

Regards,

Michael

stoeptegel wrote:

jdong wrote:I'm gonna try that download with SVN HEAD too.

Caught! I spotted you in swarm

Ha! Aren't we so nerdy

KTorrent fanatics identifying each other in a swarm of 1000+ .. BTW, I see you too, and you've given me more data than any other peer


*cough* of course, just have iptables look for the one that's bugging your UDP ports!

micha wrote:

stoeptegel wrote:+1
I download the full torrent and got no problems with data.
Are you sure you don't have parts of both versions on your system?

Quick question: May it be that certain kinds of filesystems can pose problems? I mean, regarding the preallocation of diskspace for downloaded files?!?

In _theory_ it shouldn't -- unless the filesystem is buggy enough that it's not saving the right data it's being instructed to write.

I've downloaded over 10GB of Ubuntu ISO's with KTorrent 2.0.x on XFS and EXT3 and I have never experienced any chunk corruption errors, or had any complete files fail any hash checks.

I think there's some other underlying factor here, possibly not related to KTorrent, possibly triggered by KTorrent's behavior.

John, are you on 64bit system? George don't have this problem too and he's on 64bit platform. I'm on 32bit and I got 1 out of 3 chunks corrupted on kubuntu DVD iso when I 'finished' it. Don't know if this is even related but just in case, we should know.

Ivan wrote:John, are you on 64bit system? George don't have this problem too and he's on 64bit platform. I'm on 32bit and I got 1 out of 3 chunks corrupted on kubuntu DVD iso when I 'finished' it. Don't know if this is even related but just in case, we should know.

I'm on i386...

I have downloaded 760MB of the torrent, and I just forced a hash re-check, and all the downloaded chunks verified.

I'm using reiserfs as a file system, the people who are having this problem on what file system are they downloading ?

George wrote:I'm using reiserfs as a file system, the people who are having this problem on what file system are they downloading ?

I tried both XFS and reiserfs. Corrupted chunks seemed to occur more frequently with XFS (I did not verify this exactly, but XFS was giving me lots of corrupted chunks very early while downloading, while with reiserfs I had to wait a little longer for them to occur)

I'm using ReiserFS too...

So it does not seem to be file system specific.

Maybe a stupid question, but is there enough room on the file system ?

It's not a stupid question. I had a torrent which was larger than free space on my HD. I was downloading it properly and at the end it showed me damn lots of corrupted chunks. Turned out there was more data wasted than the difference between torrent size and my free space before download started. The only thing I cannot remember is wheather or not KTorrent continued to download when I ran out of space or it showed "disk full" error

Enough free harddisk space here, corrupt chunks appear nevertheless

The ktorrent DVD finished on SVN and hashchecked correctly... I cannot reproduce this bug in SVN, and I really don't want to download again with 2.0.x....

As I said before, I run ext3 and a fairly standard Ubuntu install, and I've downloaded lots of stuff with KTorrent 2.0.x, and never experienced this bug. I think there is some other factor involved.

Well, I have a 2.0.3 installed right now to test some unrelated SVN cherrypicks for Ubuntu, I'll test this out again with 2.0.3.