the forums at degreez.net

complementory info.

As I said the repeated crc fail can start at anytime during the download, when the highest piece number is being send, but the piece _number_ is important. it's given at the time of error. I don't know how to trigger it, but it seem to happen often.

Simply check if the number of the bad crc piece corresponds to the highest piece number, and you know it will keep on failing until you restart Bittorrent

This has nothing to do with bad ram, nor with DSL or modem this is a Bittorrent bug

The really bad part is, bittorrent starts rejecting connections from people sending this, what I beleave to be, perfectly _good_ last piece, because Bittorent see them as bad at the receiving end. So if this happen early in the transfere, the torrent slows down to slug speed and all available connection are slowly rejected as junk senders (even if they are not).

Ernest.

It's often the last piece of the download, but it's not the last piece of the torrent. BitTorrent doesn't download data in any given order. The client will download other pieces around the one that's failing, and eventually the failing piece will be the last one left. And no, it's not a bug in the client, and it's also a far more stringent test than CRC. The reason why a restart sometimes fixes the problem is because of a problem with the BitTorrent protocol; it's difficult to single out a fast peer sending bad data. I'll be working on enhancements to the bad data detection routines and trying to repair that. But if your own router is corrupting the data that simply won't work. I'll be lobbying for an enhancement to the BT2 protocol to fix that problem as well.

thank for answering.

When I refere to the last piece i really meant the one with the highest number.

indeed this can happen at anytime during download, indeed it will be the last one left, and indeed this is not always the case (would be too easy if it was)

However BT tells me the number of the failling piece. Checking that number against the total, its stuningly bizzar that that number is often the highest -1 as given by BT for that download.

I juste realised that for some reason it seem to happen more often (read systematically) with the torrents I get from #digitaldistractions, and happened again a few minutes ago. This is interesting as this site only distributes there own torrents (TV stuff never send out here), and never anonymous ones. This might indicate a problem the combination of their torrent builder and BitTornado

As you have told elsewhere, restarting resolves this in seconds. forgetting to check, makes this last forever.

By the way, thanks for a great piece of soft.

cheers,

Ernest.

By the way I run
Linux 2.6.9
bittornado 0.3.7-4 (debian amd64)
python 2.3.4-5 (debian amd64)

I did patch BT1/Rerequester.py to allow for ipv6, but i seriously doubt this affects this error.
patch was from http://6net.iif.hu/index.php?mn=3&sm=9&lg=en

Ernest.
ejwtk04 at xs4all dot nl

Not at all. . The pieces are numbered from zero, so the last piece of the torrent has a piece number that is the total minus one. . You're just seeing it most often on the last piece of the torrent.

I'm wondering if part of the problem could be that the last piece of the torrent is likely to be of an oddball leftover size.

I am having the same sort of problems with hash check fails. My machine is hooked directy to modem. Its not a memory issue.

I have just read through numerous threads and I agree and understand the advise given with hash checks and "garbage" being sent from the same IP.

What works for me is simply restarting Bittornado and resume. I love Shadows version because it is small, simple and powerful. This hash check is starting to be a pain in the a$$ though.

Future request: Shadow, I have tried other BT clients (not with the same torrent files but in general) and they seem to automatically redo the hash check and resume. IE Bitcomet and Azureus

I would like to request that users not have to restart their client on hash fails. Simply because most of the downloading is unattended and if you are downloading a gig for example it is very annoying to leave the computer for hours just to come back and realize that you only completed 25% and got a hash fail and have to restart the client to resume.

1) Is there a setting in the current stable version 0.3.7 that I am overlooking that does this??
2) If not, is there a programming aspect that can just auto reload the torrent instead of having to manually restart the client. ex. when you recieve error "hash check failed" blah blah.. HALT!! .... restart...

Thanks for your dedication on this project. Your client is by far the cleanest and fastest client on older machines.

Thanks for your time

MIKEMAN

you guys might wanna check on your network monitor or backgrounds apps.
when i unload cybersitter, i get no hash error for bunch of full dvds. with cs i could have dwloaded 4gs for a 700mb mb file and still only 99.1% complete!!!!!!!!!!!!!!!!!!!!
i've tweaked all settings in cs inc. port exceptions but cs just wanna mess up every up every bit.....

guyramesh at yahoo dot com

I've been getting CRC errors lately as well. Thought I think it might have to do something with the size of the files being downloaded? I download 2-3 anime episodes every week with no problems. But when I attempt to download something over 1-2gb thats when it begins to mess up. This being a ram problem? I seriously doubt it. I've restarted the client, rebooted my computer, reset my router... And nothing. Still getting endless CRC error lops. Over 1gb downloaded off a 2.4gb file.

Figured out what was causing the CRC errors... After I checked out the help page for Azureus... http://azureus.aelitis.com/wiki/index.php/NinetyNine

I turned off the DMZ and "gaming mode", and that annoying CRC error I've been getting for a while, suddenly went poof.

Hi all, After having masive issues with a certain TV show(young teenage boy with super powers) downloading upto 2 gigs to get a 350meg AVI, I started to seek out you guys!! constant failed hash checks frustrate the shit out of me!! So My thoughts are.... in Bit Tornado 0.3.7 In Prefs and click advanced change back to NO EXTRA CHECKING from DOUBLE CHECK (which I had on BY DEFAULT as of the last few weeks) It seems to have fixed the constant Failed hash checks. I asume it will be a normal uncorrupted file once I finish it and check it!! I will repost if anyone is interested.

Hope this helps

JP

anyfedback would be great

Hey,

I've also had problems with the "Superboy" TV torrents. This is no accident, slyck.com had a story recently about content providers fighting back by having bad seeds send out bad data to try and make torrents less enjoyable to d/l.

The last 4 eps of this show have taken me roughly double the d/l to actually complete the show. Once the show is complete, everything is good, but BT is discarding huges amounts of bad data as it goes.

Another affected show is Larry David's series.

I've kind of given up on these couple of shows from BT for now and have been using UseNet. I guess that's the point, make BT a pain in the arse to use or maybe push us over our bandwidth limits.

coreyinoz

I see this problem a good chunk of the time to on the same platform. Perhaps it could be a 64 bit issue, or a debian issue. Are you using the Debian bittornado package?[/quote]i'm running a webseed with bittornado, and i got the same problems you described.
i'm runing an amd64, too, with gentoo.

:\

bittornado 0.3.7 Debian for AMD64 is borked. DO NOT USE. you will need to update to 0.3.11 from testing or 0.3.13 from unstable. there is a bug (I don't remember the details exactly, but it is a 32/64 bit conversion problem) that the last piece in the torrent will fail hash check repeatedly. it is an internal error, not people sending you bad data.