Package: rtorrent
Version: 0.6.1-1
Severity: normal
Hi,
some clients seem to have bugs in the queueing code and forget
requests made to them. In particular I see this with a BitComet client
in the Transfer list view:
452 [P: 2 F: 0]KKKKKKKKKKKKKKKKkkkkkkkkkKKKKKKKKKKKKKKKKKKKKKKKKKkkkkkKKKKKKK
496 [P: 2 F: 0]KKKKKkkkkKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
503 [P: 2 F: 0]KKKKKkkkkKKKKKKKKKKKKKKKKKKKKKKkkkkkkkkKKKKKKKKKKKKKKKKKKKKKKK
508 [P: 2 F: 0]KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK
645 [P: 2 F: 0]KKkkkkkkkkkkkkkkkKKKKKKKKKKKKKKKKKKKKKKKKkkkkkkKKKKKKKKKKKKKKK
The client is happily uploading at 20-50K/s to me but every now and
then it jumps a few chunks as you can see by the "k"s. This leaves
those blocks incomplete while it starts on more and more new blocks.
Rtorrent should notice that requests aren't replied to in the order
queued up and re-request the left out chunks.
MfG
Goswin
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.8-frosties-2
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Versions of packages rtorrent depends on:
ii libc6 2.3.6-16 GNU C Library: Shared libraries
ii libcomerr2 1.39-1 common error description library
ii libcurl3 7.15.5-1 Multi-protocol file transfer libra
ii libgcc1 1:4.1.1-5 GCC support library
ii libidn11 0.6.5-1 GNU libidn library, implementation
ii libkrb53 1.4.3-8 MIT Kerberos runtime libraries
ii libncurses5 5.5-2 Shared libraries for terminal hand
ii libsigc++-2.0-0c2a 2.0.16-3 type-safe Signal Framework for C++
ii libssl0.9.8 0.9.8b-2 SSL shared libraries
ii libstdc++6 4.1.1-5 The GNU Standard C++ Library v3
ii libtorrent9 0.10.1-1 a C++ BitTorrent library
ii zlib1g 1:1.2.3-13 compression library - runtime
rtorrent recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
