[Mldonkey-bugs] [bugs #8344] downloads pausing themself

[spiralvoice]

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

/**************************************************************************/
[bugs #8344] Latest Modifications:

Changes by: 
                spiralvoice <address@hidden>
'Date: 
                Mon 04/19/04 at 19:53 (Europe/Berlin)

            What     | Removed                   | Added
---------------------------------------------------------------------------
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
fixed in CVS 2-5-18






/**************************************************************************/
[bugs #8344] Full Item Snapshot:

URL: <http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8344>
Project: mldonkey, a multi-networks file-sharing client
Submitted by: 0
On: Sun 03/28/04 at 19:27

Category:  eDonkey-plugin
Severity:  5 - Average
Item Group:  Program malfunction
Resolution:  None
Assigned to:  None
Status:  Closed
Release:  2.5.17
Release:  
Platform Version:  Linux
Binaries Origin:  CVS / Self compiled
CPU type:  Intel x86


Summary:  downloads pausing themself

Original Submission:  ed2k downloads go to "paused" state infrequently for no 
obvious reason. this has been observed for some time now, the last version i am 
pretty sure to _not_ see it with was 2.5.3

after uncommenting some printf in donkeyOneFile.ml the "reason" shows up in the 
log:

Exception in really_write: pos=-10380 len=20810, string length=10430
...
Error Invalid_argument("Unix.write") while writing block
File paused.

all the observed auto-pausings involved a negative pos.

Follow-up Comments
------------------


-------------------------------------------------------
Date: Mon 04/19/04 at 19:53         By: spiralvoice
fixed in CVS 2-5-18

-------------------------------------------------------
Date: Fri 04/16/04 at 09:30         By: None
A temporary workaround I use is I just look up the files that exhibit this 
behaviour (for some reason it's always the same couple of files, a small part 
of the files auto pause, most files don't) and just write a script in "expect" 
to unpause them, then run that script on a regular basis.

The script looks like this:

*** Begin script ***
#!/usr/bin/expect -f
 
spawn telnet localhost 4000
expect "> "
send "auth username passwordr"
sleep 1
expect "Full Access Enabled"
send "resume 104r"
sleep 1
send "resume 98r"
sleep 1
send "qr"

*** End Script***

Fill in your own username/pass combination, and of course the indices of the 
problematic files (104 and 98 in my case).

Then I just start a screen session and in there I run the command with:

while (true) ; do sleep 60 ; ./mldonkey-unpause ; done

Yup, I know, shoddy workaround, but it beats babysitting a file that 
auto-pauses every couple of minutes and that's only downloaded for 50/350 MB...

-------------------------------------------------------
Date: Wed 04/14/04 at 21:26         By: None
I tried a full fsck on my clean filesystems. Nothing reported by fsck, so i 
guess the problem is not there. The problem is visible on NetBSD's FFS with 
softdep and Linux's ext3. 

Karsten Kruse - tecneeq at tecneeq.de


-------------------------------------------------------
Date: Sat 04/10/04 at 20:07         By: None
the negative offset does not seem to be caused by a FS-problem. more the result 
of some network-io related error ("uh, socket dead") causing an out-of-order 
write with a buffer that is not full yet, but passing the buffersize to write 
instead of the how-much-bytes-in-buffer-right-now. look at the example above 
("pos" == ("string length" - "len")) and (pos < 0) has been true for all cases 
of sudden-pause logged here.

i tried tracing code to figure out who passes the wrong arg, but i do not know 
enough ocaml.

-------------------------------------------------------
Date: Wed 04/07/04 at 07:02         By: chemical
I can confirm this issue, seems to be in conjunction with the 
unix.write-function and/or a possible damaged file system which should be 
unmounted and checked by fsck even if its "clean" 












For detailed info, follow this link:
<http://savannah.nongnu.org/bugs/?func=detailitem&item_id=8344>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.nongnu.org/