aMule Forum

English => en_Bugs => Topic started by: byteforge on November 08, 2015, 02:49:52 PM

Title: 2.3.1 "infinite download loop" bug
Post by: byteforge on November 08, 2015, 02:49:52 PM
This bug might only affect 2.3.1 on Linux.

Anyways, it's starting to drive me nuts.

Supposing I'm downloading a RARE 400 MB file, 235 done, 165 to go.
Now I've observed the following:
All sources but one will switch to "No needed parts". This is OK. But now listen:
One lone 2.3.1 client will still let me download, pretending to have more parts of the file than the others have.

Downloading will continue, 235.5, 237.0. 238.5, 240...BUT then from some point, the erroneous parts count will increase and an auto-check will be triggered, causing the the to (repeatedly) fall back to 235.0.
Download will commence again, retry ... and fall back again.
I've noticed this behavior 10 times in a sequence, and the file would never get finished.

And mind you: even if I did upgrade to 2.4.0 (SVN), I might not be able to circumvent this issue because the other side is still using 2.3.1 with the bug still in.

The only (emergency) way out currently is to ban the IP in question via ipfilter_static.dat.




Title: Re: 2.3.1 "infinite download loop" bug
Post by: GonoszTopi on November 18, 2015, 11:54:16 AM
Hmmm.... CorruptionBlackBox should have banned the bad guy...
Title: Re: 2.3.1 "infinite download loop" bug
Post by: byteforge on November 18, 2015, 06:09:38 PM
Well, I wouldn't go as far as calling him a "bad guy".

Except for the "broken" parts, he had same clean parts like the others had as well; it was plain to see in the graphics in the lower pane.

Can you be more specific about the option you're talking about please? I wouldn't even know where to set it...
And in case it's supposed to work automatically: how can I alter the threshold from which percentage of corrupt data the banning will take place? (Note again: I'm on amule LINUX, and it may still be lacking features available in the Windows builds.)

Ah, and why are you so sure it's not 2.3.1 at fault here?
I only have this problem if the other side uses 2.3.1. So I'm still thinking the culprit is the client version, not the user himself.