Your message dated Mon, 9 Jan 2006 20:18:00 +0000
with message-id <[EMAIL PROTECTED]>
and subject line Bug#346283: rtorrent: Stays stuck missing the last chunk for a
long time
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--------------------------------------
Received: (at submit) by bugs.debian.org; 6 Jan 2006 19:32:53 +0000
>From [EMAIL PROTECTED] Fri Jan 06 11:32:53 2006
Return-path: <[EMAIL PROTECTED]>
Received: from mx5.informatik.uni-tuebingen.de ([134.2.12.32])
by spohr.debian.org with esmtp (Exim 4.50)
id 1EuxKX-0002nM-2b
for [EMAIL PROTECTED]; Fri, 06 Jan 2006 11:32:53 -0800
Received: from localhost (loopback [127.0.0.1])
by mx5.informatik.uni-tuebingen.de (Postfix) with ESMTP
id 0C309115; Fri, 6 Jan 2006 20:32:21 +0100 (NFT)
Received: from mx3.informatik.uni-tuebingen.de ([134.2.12.26])
by localhost (mx5 [134.2.12.32]) (amavisd-new, port 10024) with ESMTP
id 13216-02; Fri, 6 Jan 2006 20:32:18 +0100 (NFT)
Received: from localhost.localdomain (semeai.Informatik.Uni-Tuebingen.De
[134.2.15.66])
by mx3.informatik.uni-tuebingen.de (Postfix) with ESMTP
id A7276145; Fri, 6 Jan 2006 20:32:16 +0100 (NFT)
Received: from mrvn by localhost.localdomain with local (Exim 4.50)
id 1EuxJv-0003Im-43; Fri, 06 Jan 2006 20:32:15 +0100
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: Goswin Brederlow <[EMAIL PROTECTED]>
To: Debian Bug Tracking System <[EMAIL PROTECTED]>
Subject: rtorrent: Stays stuck missing the last chunk for a long time
X-Mailer: reportbug 3.9
Date: Fri, 06 Jan 2006 20:32:15 +0100
Message-Id: <[EMAIL PROTECTED]>
X-Virus-Scanned: by amavisd-new (McAfee AntiVirus) at
informatik.uni-tuebingen.de
Delivered-To: [EMAIL PROTECTED]
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE
autolearn=no version=2.60-bugs.debian.org_2005_01_02
Package: rtorrent
Version: 0.3.4-1
Severity: normal
Hi,
i noticed on many ocasions that rtorrent downloads a torrent down to
the last chunk and then gets stuck. This state can last for hours or
days until the torrent completes. From what I can figure out it is not
a case of the file being incomplete but of rtorrent not requesting the
last block:
DNS UP DOWN PEER C/RE/LO QS DONE REQ SNUB
84.9.168.242 2.8 0.0 11.9 l/ci/un 0/0 55
172.202.237.67 0.0 0.0 0.0 l/cn/cn 0/0 100
82.28.2.0 3.8 0.0 10.2 l/ui/un 4/0 76
85.96.179.56 0.0 0.0 10.2 l/ci/ci 0/0 75
67.168.60.195 0.0 0.0 5.1 r/ui/cn 0/0 37
70.30.56.194 0.0 0.0 0.0 l/ui/cn 3/0 45
66.130.176.66 0.0 0.0 8.5 l/ci/ci 0/0 22
84.84.195.6 2.7 0.0 10.2 l/ci/un 2/0 20
70.226.129.185 0.0 0.0 18.8 l/ci/cn 0/0 6
87.196.23.20 0.0 0.0 0.0 l/cn/ci 0/0 100
211.30.143.45 0.0 0.0 3.4 l/ci/cn 0/0 53
68.3.236.102 0.0 0.0 0.0 l/cn/ci 0/0 100
81.168.155.76 0.0 0.0 0.0 l/un/cn 0/0 100
70.50.57.48 0.0 0.0 18.8 l/ci/ci 0/0 86
83.134.90.198 0.0 0.0 1.7 l/ci/cn 0/0 7
...
^ ^ ^
| |_________/
'i' means they have the missing chunk, right? |
|
But rtorrent has not requested any chunks from any client, right?
MfG
Goswin
-- System Information:
Debian Release: 3.1
Architecture: amd64 (x86_64)
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.2.ds1-22 GNU C Library: Shared libraries an
ii libcurl3 7.13.2-2 Multi-protocol file transfer libra
ii libgcc1 1:4.0.0-12 GCC support library
ii libidn11 0.5.13-1.0 GNU libidn library, implementation
ii libncurses5 5.4-4 Shared libraries for terminal hand
ii libsigc++-2.0-0 2.0.10-1 type-safe Signal Framework for C++
ii libssl0.9.7 0.9.7e-3 SSL shared libraries
ii libstdc++5 1:3.3.5-13 The GNU Standard C++ Library v3
ii libtorrent5 0.7.4-1 a C++ BitTorrent library
ii zlib1g 1:1.2.2-4 compression library - runtime
-- no debconf information
---------------------------------------
Received: (at 346283-done) by bugs.debian.org; 9 Jan 2006 20:18:31 +0000
>From [EMAIL PROTECTED] Mon Jan 09 12:18:31 2006
Return-path: <[EMAIL PROTECTED]>
Received: from mta08-winn.ispmail.ntl.com ([81.103.221.48])
by spohr.debian.org with esmtp (Exim 4.50)
id 1Ew3TL-0002oJ-Ei
for [EMAIL PROTECTED]; Mon, 09 Jan 2006 12:18:31 -0800
Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35])
by mta08-winn.ispmail.ntl.com with ESMTP
id <[EMAIL PROTECTED]>
for <[EMAIL PROTECTED]>; Mon, 9 Jan 2006 20:18:00 +0000
Received: from rabbit.zoo.mayhq.org ([80.0.127.238])
by aamta09-winn.ispmail.ntl.com with SMTP
id <[EMAIL PROTECTED]>
for <[EMAIL PROTECTED]>; Mon, 9 Jan 2006 20:18:00 +0000
Received: (qmail 5336 invoked by uid 1000); 9 Jan 2006 20:18:00 -0000
Date: Mon, 9 Jan 2006 20:18:00 +0000
From: Qingning Huo <[EMAIL PROTECTED]>
To: Goswin Brederlow <[EMAIL PROTECTED]>,
[EMAIL PROTECTED]
Subject: Re: Bug#346283: rtorrent: Stays stuck missing the last chunk for a
long time
Message-ID: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature"; boundary="pf9I7BMVVzbSWLtt"
Content-Disposition: inline
In-Reply-To: <[EMAIL PROTECTED]>
User-Agent: Mutt/1.5.11
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02
(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Level:
X-Spam-Status: No, hits=-10.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER,
HAS_PACKAGE,RCVD_IN_SORBS autolearn=ham
version=2.60-bugs.debian.org_2005_01_02
--pf9I7BMVVzbSWLtt
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Package: rtorrent
Version: 0.4.1-1
On Fri, Jan 06, 2006 at 08:32:15PM +0100, Goswin Brederlow wrote:
> Package: rtorrent
> Version: 0.3.4-1
> Severity: normal
>=20
> Hi,
>=20
> i noticed on many ocasions that rtorrent downloads a torrent down to
> the last chunk and then gets stuck. This state can last for hours or
> days until the torrent completes. From what I can figure out it is not
> a case of the file being incomplete but of rtorrent not requesting the
> last block:
>=20
> DNS UP DOWN PEER C/RE/LO QS DONE REQ SNUB
> 84.9.168.242 2.8 0.0 11.9 l/ci/un 0/0 55
> 172.202.237.67 0.0 0.0 0.0 l/cn/cn 0/0 100
> 82.28.2.0 3.8 0.0 10.2 l/ui/un 4/0 76
> 85.96.179.56 0.0 0.0 10.2 l/ci/ci 0/0 75
> 67.168.60.195 0.0 0.0 5.1 r/ui/cn 0/0 37
> 70.30.56.194 0.0 0.0 0.0 l/ui/cn 3/0 45
> 66.130.176.66 0.0 0.0 8.5 l/ci/ci 0/0 22
> 84.84.195.6 2.7 0.0 10.2 l/ci/un 2/0 20
> 70.226.129.185 0.0 0.0 18.8 l/ci/cn 0/0 6
> 87.196.23.20 0.0 0.0 0.0 l/cn/ci 0/0 100
> 211.30.143.45 0.0 0.0 3.4 l/ci/cn 0/0 53
> 68.3.236.102 0.0 0.0 0.0 l/cn/ci 0/0 100
> 81.168.155.76 0.0 0.0 0.0 l/un/cn 0/0 100
> 70.50.57.48 0.0 0.0 18.8 l/ci/ci 0/0 86
> 83.134.90.198 0.0 0.0 1.7 l/ci/cn 0/0 7
> ...
> ^ ^ ^
> | |_________/
> 'i' means they have the missing chunk, right? | =20
> |
> But rtorrent has not requested any chunks from any client, right?
>=20
> MfG
> Goswin
>=20
Hi,
This bug should be fixed in the latest version of rtorrent (0.4.1-1). I
am closing the bug now. Please feel free to reopen it if you think the
problem is not solved.
Regards,
Qingning
--pf9I7BMVVzbSWLtt
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDwsT4fYhzMmgvs9oRAl9NAJ4uEF7gh2mICSqhoj23Ej2yrH6FwwCfeWK/
OW4h5UMukkABEGRzyTrsGcA=
=37/U
-----END PGP SIGNATURE-----
--pf9I7BMVVzbSWLtt--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
