Spruious `completed' announces sent to tracker

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Download some torrents
2. Seed them for a while
3. Occassionally, a `completed' announce is sent.

What is the expected output? What do you see instead?

As far as I understand by reading [1] and [2], a `completed' announce should 
never be sent for a torrent that has already finished downloading.

[1] https://wiki.theory.org/BitTorrentSpecification#Tracker_Request_Parameters
[2] 
https://wiki.theory.org/BitTorrent_Tracker_Protocol#Basic_Tracker_Announce_Reque
st

What version of the product are you using? On what operating system?

Deluge 1.3.6
Libtorrent 0.16.15.0

Arch Linux
> uname -a
Linux 3.13.6-1-ARCH #1 SMP PREEMPT Fri Mar 7 22:47:48 CET 2014 x86_64 GNU/Linux

Please provide any additional information below.

A couple private trackers I use notified me that my client seems to be sending 
out spurious `snatches', i.e., notifying the tracker that is has finished 
downloading a torrent. On the order of hundreds of times a month.

I turned on debugging today and let it run for a while. The torrents 
`slackware-14.0-iso', `anomalywarzoneearth-1331597867-installer', and 
`rochard-linux-1.32_rc3-1354236999-amd64.deb' (and others) end up sending 
`completed' announce to the tracker. However, all of these have been complete 
and seeding for over 20 weeks. The attached log is rather long, because I'm not 
sure which messages might be related and didn't want to delete too much. I 
recommend searching for the torrents in question or (completed) might be more 
helpful.

I've uploaded the log here:
https://gist.github.com/bluephoenix47/8899d31481d7054b252c

Original issue reported on code.google.com by BluePhoe...@gmail.com on 5 Aug 2014 at 8:00

[GoogleCodeExporter]

thanks for the report. I'll have to look into this.

Original comment by arvid.no...@gmail.com on 6 Aug 2014 at 5:42

[GoogleCodeExporter]

Thanks. After some recommendations on #libtorrent, I'm trying to get some logs 
from a build of libtorrent with --enable-logging=verbose, and possibly some 
wireshark traces.

Original comment by BluePhoe...@gmail.com on 6 Aug 2014 at 6:13

[GoogleCodeExporter]

I compiled 0.16.15 with debugging and verbose logging, and ran a seperate 
deluge instance (with fewer torrents) until I got a bunch of spurious 
completed. The libtorrent logs, and the deluge log, are here:
https://dl.dropboxusercontent.com/u/61793619/logs.tar.gz

Original comment by BluePhoe...@gmail.com on 6 Aug 2014 at 7:35

[GoogleCodeExporter]

this is what I think is causing this:

each tracker has a flag specifying whether or not we've sent "completed" to it 
or not. If we haven't and the torrent is complete, we'll send it. If we get a 
response from a "completed" announce, and the torrent is seeding, we set this 
flag.

However, this flag is not persisted in the resume data, nor reset when adding a 
torrent. This, presumably, has the effect that every time the client is 
restarted, these flags will be cleared, and another completed announce is sent.

Original comment by arvid.no...@gmail.com on 7 Aug 2014 at 4:36

[GoogleCodeExporter]

hm. except, I just found the place where this logic belongs in 
torrent::files_checked(), and it's already there...

Original comment by arvid.no...@gmail.com on 7 Aug 2014 at 4:43

[GoogleCodeExporter]

Could you please test this patch? This is on the theory that deluge likes to 
use replace_trackers() (possibly for no reason).

http://dpaste.com/1SKSNS3

I've checked this into all active branches.

Original comment by arvid.no...@gmail.com on 7 Aug 2014 at 5:00

[GoogleCodeExporter]

I just installed a new version with that patch. Last time it only took about 30 
minutes for the spurious completed's, but I've been running for 1.5 hours and 
haven't seen any yet.

Original comment by BluePhoe...@gmail.com on 7 Aug 2014 at 3:47

[GoogleCodeExporter]

We do use replace_trackers whenever settings trackers, and this does occur 
after loading the state as we store trackers ourselves. Not sure if that is 
classed as 'for no reason' ;)

Thanks BluePhoenix for following up on this. 

Original comment by caluml...@gmail.com on 7 Aug 2014 at 7:16

[GoogleCodeExporter]

Happy to help. I'm going to install this patch on my normal system and keep an 
eye out for spurious completed's, but my test instance seems to be fixed.

Original comment by BluePhoe...@gmail.com on 7 Aug 2014 at 7:22

[GoogleCodeExporter]

thanks!

Original comment by arvid.no...@gmail.com on 7 Aug 2014 at 8:07

• Changed state: Fixed