the forums at degreez.net

As topic says, it fails to download last piece of a torrent.. it tries to download it again and again..

i just messages like:

[22:03:30] piece 163 failed hash check, re-downloading it

and it goes like that forever

if i exit the program, and resume, it downloads the remining piece with no problems (and completes the download).

the torrent is ok.. tried with several ones... even one with only one source that im pretty sure is ok (to discard corruption problems on client's side)

behavior is the same for gui and ncurses interfaces


Greetings!

btw, I'm running freebsd amd64 with python 2.4

Step 1: Close and resume the torrent.

Step 2: Disconnect your router and plug your computer directly into your uplink, then close and resume the torrent. (I'm assuming you have a router.)

Step 3: See if you can get a different ethernet card, and try that.

This works, it finish the download at first attempt.



Nope, Im connected directly to DSL modem



I'll try.


Someone on freebsd mailing list suggested to try BitTorrent (to discard any torrent/python/machine problem), and it works, it finish the download at first attempt (no hash failures).


Could this be a bug in the program rather than local problems ?

It's a problem with the ability of the program to reject bad peers that exhibit certain behavior. I'm working on it.

I know this might sound stupid but let's say it's a movie you're downloading and getting all the data bit for bit isn't that important.

Is there anyway to ignore the hash chack?

I find if i dont complete the download i cant even play the movie unless i use AVI preview. Its better to complete the download seriously less headaches. I dont believe Shadow has considered having an opition to disable Hash.

Disable hash check, so you'll be uploading bad data to other peers in the swarm? Oh, hell no.

There's also an option on the Prefs page to kick/ban clients who send bad data. I usually leave this unchecked, but if I get an unusual of hash-type errors, I turn it on. This might help if you're repeatedly retrieving the same (bad) chunk from 1 peer.

Garry

This is ok for a movie, its unacceptable for an ISO file, especially if it is an operating system (I'm testing with freebsd).


To eliminate problems with bad client data, I tried a torrent with exactly one client.

It is the same behavior, it downloads fine until last piece, after that it fails checksum again and again. Stoping and resuming finish the download w/o problems.

That's not good. Do you also occasionally get exception windows coming up, with "pop from empty list", or "assertion error"?

nope, no popup windows at all

also using the curses client only shows a list of the hash errors.. and that is all.

I've never run into this behavior myself. So what you're saying is, you had the failure come up with this peer, then when you disconnected and reconnected you got the good piece from the same peer.

This could be:

(1) The piece data list getting corrupted in the engine; I'll add a consistency check to pop up an error if that's so. This is unlikely though because you aren't getting any other consistency check errors.

(2) A failure in the engine that results in a bad state. This could be caused by a programming error or by Python getting corrupted. The corruption is unlikely because you aren't getting any other consistency checks popping up. A programming error is also unlikely because with all the downloading I do I'd expect to see it pop up myself.

(3) Something in the networking end, software or firmware, entering a bad state. Despite this sounding unlikely, I would bet this is the problem.

I posted this problem weeks ago in a different thread. It seems that the problem is related to AMD64 OSes. Does anybody run an AMD64 OS (e.g. Linux, FreeBSD) and does not have this problem?
I don't think it has anything to do with the network hardware. It's always the last part of a download with the highest part number. Usually it's working after closing the client and resuming the download. But not always as I have two D/L that aren't finishing even if I resume them. A different download was finishing at the first attempt after encountering more than 100 hash checks.

Marco

maybe it's a little late to post on this thread but i'm on gentoo linux amd64 and i have this problem with every torrent, i have always used bit tornado (shadow client) and i think it's very good, so if i can help by providing information just let me know.

this behavior is not exclusive to large torrents, it happens to every torrent, and started happening just as i moved into 64 bits.

-m