Wed 11 May 2005 04:06:02 PM UTC, comment #6:
I'm the author of #2 & #4 comments :-) (mldonkey 2.5.30-15 spiralvoice, win2k)
Well, the torrent downloads very well (great speed) but in the last blocks (5-8) mldonkey writes in the log messages like these:
-----------
Verification of complete block 178 of mytorrent FAILED, redownloading it.
Verification of complete block 1072 of mytorrent FAILED, redownloading it.
Verification of complete block 352 of mytorrent FAILED, redownloading it.
-----------
It is the same with all the torrents.
These error is the same reported in : http://mldonkey.berlios.de/modules.php?name=Forums&file=viewtopic&t=3379&sid=a108a3636a8c29df4727868e1f2e8473
|
Sun 21 Nov 2004 12:37:24 AM UTC, original submission:
I downloaded core 28h from spiralvoice's page and installed it on Win2K SP2 from scratch with default configs. Edonkey (with Overnet and Kad) works just fine, but BitTorrent does something strange. It gets the .torrent file, connects to a tracker and starts downloading with pretty good speed. Unfortunately, as soon as it downloads a chunk, it immediately drops it and looks for another source to retry it from. This repeats ad infinitum. It looks hash-related to me (after all, it refuses a chunk it just downloaded - wrong hash seems to be very probable reason).
I downloaded another core, this time 28g with swarming from White FrosT. With exactly the same result.
With very small torrents (say, 200 kilobytes) it's painfully obvious what happens: the file gets downloaded in a few seconds from a source, then discarded as a whole (downloaded size becomes zero) and then mlDonkey connects to another source and repeats the process. With larger files it looks as if multiple chunks start downloading, and they get discarded as they are finished, so total amount goes up for a megabyte or two, and then jumps down in pieces of about 300K (AFAIR, typical chunk size is 256KB?).
Next I tried core 16r for Windows from White FrosT and it works just fine, this bug is not present, but it doesn't seem to work with multi-file torrents for me (doesn't even show them in downloads), and they are very common these days.
I tried Linux version of 28h static then (had to install SlimLinux especially for it :), and it seems to be working fine too (all the tests were on the same set of torrents, of course, and within minutes from each other). Perhaps it's windows-related bug?
And, just as a first impression, not even a feature request - mldonkey is very, very hard to identify bugs in and sometimes even uncomfortable to download with: no visual feedback about most things (is it still downloading the .torrent file from URL or the download failed already? what's the situation with this particular file in the downloads - why it isn't loading, and is it even trying?) and no easily accesible logs or meaningful status details... And I don't mean various GUIs here - it's the core that doesn't give them (ot telnet/www user) enough data for that "responsive" feeling... Simple status messages, server and/or tracker responces (for GUIs to show next to file name, of course, in real time), that kind of thing, could help a lot without being too bothersome to implement.
|