[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mldonkey-bugs] [bugs #11073] Torrents constantly re-downloading

From: anonymous
Subject: [Mldonkey-bugs] [bugs #11073] Torrents constantly re-downloading
Date: Sat, 20 Nov 2004 19:45:57 -0500
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

This mail is an automated notification from the bugs tracker
 of the project: mldonkey, a multi-networks file-sharing client.

[bugs #11073] Full Item Snapshot:

URL: <>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: 0
On: Sat 11/20/2004 at 19:37

Category:  Bittorrent-Plugin
Severity:  5 - Average
Item Group:  Program malfunction
Resolution:  None
Privacy:  Public
Assigned to:  None
Status:  Open
Release:  2-5-28
Release:  Multiple
Platform Version:  Cygwin W2K/WinXP
Binaries Origin:  Downloaded from third-party page
CPU type:  Intel x86

Summary:  Torrents constantly re-downloading

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.

For detailed info, follow this link:

  Message sent via/by Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]