the forums at degreez.net

Boy it's fustrating when you're downloading an 8.8GB torrent that takes around a week with your crumy internet connection, and you loose the lot!

I moved the disk that had this torrent 80% completed, and it ended up copied on a reiserfs4 partition copied from an ext3 partition.
Bit tornado scanned the whole torrent (now on an reiserfs4 fs) and decided my 80% complete torrent was empty and started again!
The fustration!!

I don't quite know how the code works - but I tried again and because it cleverly remembers what it's already scanned it instantly started off where it left off - 0% and I don't know how to make it rescan..

Shrug I say - it's moved file systems, I guess that's to be expected the data will now be looking rather different.
So I did a test, copied another partially completed torrent to a different location on the same partition (and hence same filesystem) - and again it started from scratch! Which I found interesting. No mixing file systems at fault this time - so it seems it's not really reading the data properly?

Weird I thought, but I guess it just means I have to stick with the same file(s) the whole time - not normally a problem.

So I start my 8.8GB torrent from the start again, on my local ext3 partition. Several days later I made it to about 60%, computer hung, I resumed the torrent and HEEEEEY!!!! I'm back to zero again!!!!

This is the original files in the same location of the same parition! WTF? Something is very wrong here! I can accept the possibility of some data corruption, and loosing a few MB - but again I've lost the lot.

Any suggestions on what's going on here.

I've now wasted around 2 weeks on downloading round the clock because bit tornado keeps loosing the plot!

Thanks,
Gr|ffous

Just wondering do you save to a NTFS file system?
Since fat32 cant take more than 4 gigs.

ReiserFs and Ext3 are linux file systems that are similar to Ntfs in means of data consistency.

you can make bittornado rescan your files by deleting corresponding datacache file in ~/.BitTornado/datacache
by the way when you run 'du -sh' in the directory where you have your files what does it say?

volpol: 7.6G
so it's still all there

WaveOfFire, I'm using ext3 in this case - not windows.

I'm doing a rescan in case that will help somehow now

Gr|ffous

Aaand no.

It's weird, the torrent is a number of video clips, and I just watched 2 of them that had finished ( I prioritised them) and they are fine.. the data is fine!
yet bit tornado keeps starting again.

Gr|ffous

i have no clue. try copying data to a non-journaling filesystem and make bit tornado rescan it. the next thing you could try is probably voodoo magic.

The problem has still been dogging me - so I did a bit of testing.
Using Bt 0.3.7 I have this problem. I'll resume my file and it just starts from scratch - EVEN IF I clean out my ~/.Bittornado which forces a rescan.

I use gentoo, so I unmerged bittornado, and put in the standard bt client. Resumed the download and it worked perfectly..

Emerged Bittornado 0.3.7 again, and it started from scratch again - so it's not my torrent, or the torrent data - it's the client.

I tried Bittornado 0.3.1 (the stable version according to gentoo) and this worked fine.

So I've established there is a bug somewhere between these versions.
I'll try and narrow the version number down a bit further if I can find the time but can a developer please look at this?

Thanks,
Gr|ffous

i am not sure it is the client. i tested the client with ext3 (using loop since my partitions are all reiserfs3 ) and had no problems. try downloading the tarball from the site and test it. maybe the bug is introduced by some gentoo specific patch? i'm on debian sid.

Hi Volopol, Thanks for following this with me

Well, I can't see the issue being a filesystem issue - for two reasons.
Firstly, I've always used ext3 and not had an issue, and secondly my most recent test of doing nothing more then unmerge 3.7, and remerge 3.1 tells me that it's the software itself.
Also the standard client which I had another try with - also had no issues resuming the same torrent and data.

I gather that you're hinting that it might be some kind of gentoo patching and you want me to try the direct source. I don't see anything patched as it compiles but I'll have a go at this after work today. and let you know what the results are.
Another point to note is that I'm running amd64 - I wonder if this has something to do with it.

I'm fairly sure I also had the latest version working with my old machine and didn't have any issues, but on my present machine at least it seems clear that the latest versions of the bit tornado client don't resume properly

Update: 3.6 does the same thing.

The final possible clue to add is that once 3.6/3.7 finishes scanning it doesn't start from the very beginning, it did remember a little data.

So my 7GB torrent, which was at 87% last I saw, it did it's big scan and started from 1.6MB.
This 1.6 I believe is simply the amount of data that has come down when I've been fiddling between versions - so it's almost as if the later versions start again in a different way in which they store the torrent chunks.

However it's not that the later versions do store it differently and hence the two are not compatable I don't think, because a couple of smaller torrent which I've downloaded exclusively with the new client have had this same problem.

Gr|ffous

Does any of that shed any light?

I also get this same problem. I am also using gentoo/amd64 setup and the emerge for 0.3.7 and 0.3.6 have this same issue. Though unfortunately I haven't found a solution to this yet...

I also had something similar but different. I ran out of disk space. I freed up disk space and then had to restart to get it to start connecting to peers again. It found my files and scanned them and showed the correct percentage downloaded but wouldn't connect to any peers for download or upload. I found, after awhile of trying things, that if I did a 'ps x' I had a bunch of hung btdownloadgui.py processes. I killed those, restarted and away it went.

What version of Python are you using when you have the issues with resuming in BitTornado?

Also, have you tried grabbing the Python source code from: http://www.python.org/download/
and then compile it, then try resuming in BitTornado with that python?

I wonder if this could be an amd64 problem since I've also experienced this and I'mn running on an Athlon64. I've also experienced another problem which I think might be amd64 related: Often I will reach about 99.9% complete on a torrent and then BitTornado will proceed to reject the last chunk repeatedly saying it has a bad hash. Stopping and restarting the torrent usually solves this and will then complete the download, but occasionally I get your problem of the torrent practically starting over.

(See this topic for more info about the completion problem)

Its not just a 64bit problem...

I'm using bittorrent/bittornado on debian sarge off a pentium 166...

Had partial files downloaded and upon using bittornadocurses they came up as 0%... removed datacache files for the rescan and still 0%...

I had stopped the d/l's imediately both times.
Fired up bittorrentcurses again and after the rescan they were all fine, started from where they should have....