Summary: | amule is corrupting downloads | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bruno Lustosa <bruno> |
Component: | Current packages | Assignee: | Gentoo net-p2p team <net-p2p> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://www.lustosa.net/files/amule.png | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Bruno Lustosa
2005-05-24 19:09:49 UTC
there's more than one amule version... Sorry, here is the specific version with use flags: net-p2p/amule-2.0.0_rc7 -debug +gd -gtk2 +nls -remote -stats -unicode Could you try to download file with amule-2.0.1? (In reply to comment #3) > Could you try to download file with amule-2.0.1? Will try it at home and then post. amule-1.2.8 is working fine here at work. Karol, I just got the same problems again, using 1.2.8 at work. Still haven't tested new 2.0.1 at home, will try later. At work, this is what I am using: net-p2p/amule-1.2.8 -debug +gtk2 +nls -remote I got a screenshot of the transfer window. You might want to see it. Address is at URL field of this bug. I'm not sure whether this is an amule problem or a corrupted file at the origin, but the file I'm downloading had over 20 sources. Karol, just an update. I just tested the file I downloaded, and in fact, it was all ok, though the transferred column was way lower than the actual file size. It didn't corrupt. What shall it be? Super compression? I'm confused. Err, this is not corruption at all (unless the completed doesn't match the target ed2k hash, you can use alc or ed2k-hash to calculate this outside of aMule), this is simply a result of the zlib compression *Mule clients apply to large packets, including block-packets. You can even see how much you've gained thanks to compression by right-clicking on a queued file and selecting "Show file details" and the looking at the "Gained by compression:" value. Alright, my fault. Sorry for taking your time. |