|
Notes |
|
|
(0001080)
|
|
Kry
|
|
2005-06-17 17:59
|
|
|
That can't happen. Once completed, files are touched no more. |
|
|
|
|
Try this:
When the file has been completed and you've taken steps to reproduce the problem, shut down aMule and then use the 'touch' utility on the file. Then restart aMule, which will then rehash the file. If the hash now reported on the file doesn't match what it was originally in the ed2k link, then the file has been corrupted locally, if not, then the file was bad when originally shared.
Please report the results of this. ;)
Cheers,
Xaignar |
|
|
|
|
Hello Xaignar,
I followed the procedure as outlined in your note, and the hash has indeed changed. But I already knew that the files are corrupted locally, since they usually play just fine when I open them immediately after the download has finished, and only later on show signs of corruption.
I have no clue why this happens. I also noticed that I don't really have to click "Clears completed downloads" for this to happen, it seems this happens after a certain period of time has passed even if I don't touch anything. This time, though, it happend after a simple reboot (because I installed a new kernel).
If this isn't aMule's fault, as Kry noted, what else could be causing this to happen, and why are only single .mp3's affected? I find this quite confusing and disturbing.
But other than that, I am very happy with aMule. :) |
|
|
|
(0001107)
|
|
Kry
|
|
2005-06-25 20:03
|
|
Well, no idea. Absolutely no idea. Once downloaded, files are not open by aMule anymore, as I noted above. this gotta be some problem with kernel (tho you now say you changed it), filesystem (related to kernel) or hdd (my bet).
What's weird is, only mp3 files are affected. But think might be related to the size of the files. Why don'y tou donload i.e. a .rar file that has ~ the same size than an mp3 and check if it gets corrupted? Any binary-sensitive file like rar, zip, etc would do. |
|
|
|
|
Kry,
Good call. You were right about the file size, it happend to a .rar archive (<5MB) too, kind of spooky. I then switched the incoming and temp directories to a different file system, and so far, the corruption has not appeared (yet). Previously, those directories were on a FAT32 partition, which contains several GB's worth of .mp3's, and the corruption only takes place in aMule's incoming folder, so I thought it was an aMule-specific problem. FreeBSD's native file system doesn't seem to have a problem with that (yet).
It's still weird, though. If it really only is a matter of the file system, why are only smaller files affected, and why are only the files of a single directory affected? |
|
|
|
(0001109)
|
|
Kry
|
|
2005-06-25 21:31
|
|
That might be way beyond my possibilites of knowing it ;)
As this is not an aMule bug, can we close it and continue discussion on the forums? I hate to have nonbugs laying aorund the Mantis software ;) |
|
|
|
|
It is possible that the FAT32 filesystem is messed up. By any chance can you run the equivalent of fsck* on it? You should probably also check your kernel logs for hardware related errors, though that doesn't seem all that likely considering the syntoms.
* Dunno if there is a nix util for that and can't recall the name of the Windows utility for doing it. :P |
|