Seed status not reported to tracker

[flvinny521]

I apologize if this has already been reported. I tried searching for an active issue, but didn't seem to find anything related.

Using Deluge 1.3.11, seeding torrents are not reported correctly to the tracker, resulting in an inability to seed. I have approx 2600 completed torrents on a dedicated seedbox/media server in my home. Most of them belong to one specific private tracker, but in all, there are 6 private trackers represented. Although Deluge reports all these torrents as seeding, the trackers see only a fraction of my torrents as seeded. For testing purposes, I increased the number of active torrents to infinite. Pausing and resuming torrents correctly reports the status again, but at the next announce period, the torrents stop reporting correctly again. This issue also occurs with qBittorrent 3.2.1 and 3.2.3. as seen here.

[arvidn]

could you please provide details about:

1. version of libtorrent that exhibit this problem
2. what exactly is the problem? The ability to seed does not rely on reporting left=0 to the tracker. As long as you receive peers (from the tracker, DHT or PEX) you can seed. Could you provide an example announce request that is incorrect, and what you would expect instead?

[flvinny521]

I assume Deluge is using libtorrent 0.16, based on the changelog for the current release.

EDIT: libtorrent 0.16.18.0

I may be wrong about not being able to seed. I assumed that if tracker reports me as not seeding a particular torrent, then I will not be able to seed that torrent if somebody begins to leech it. If that is not the case, I apologize for my misunderstanding. However, the issue is still important, because I am getting "Hit N Run" warnings from most of my trackers. I worked hard to get a good reputation on these sites, and I would not like to jeopardize that by this bug affecting my seeding stats.

[arvidn]

The problem is that I don't really know what "Hit N Run" means. I know the bittorrent protocol, and it would be really helpful if the symptom you see could be explained in terms of the protocol. From qBT thread, I gather it means either (1) you announce that you're stopping the torrent immediately as you complete it (2) you simply stop announcing entirely once completed, and the tracker assumes you disappeared.

One possible variation would be: (3) that you stop announcing when you complete, only to announce that you stop when you shut down your client. From the tracker's point of view, you didn't complete the torrent until you shut down. Can you tell if you see any indications whether it's (1), (2) or (3)?

[flvinny521]

I am not entirely sure, to be honest. I recently migrated all my seeds from my PC to a standalone server, so they were all added in an already downloaded, complete state. I have only added a handful of new torrents since then. There does not seem to be any consistency regarding WHICH torrents are not announced. As also mentioned in the other thread, pausing and then resuming the torrents does re-announce to the tracker that the torrent is active, and the tracker will once again show the correct status of all of the seeds. It's on the following announce schedule that the tracker no longer lists the torrent as seeding.

I really don't know anything about the protocol; I am just an end-user, but I can follow any instructions you can provide if I can test any of these possibilities for you.

[Buitenlust]

i'm having the same issue in qbittorrent v3.2.3 (libtorrent 1.06 ?)
Seems like there is a problem with announcing the torrents in seeding status.
The tracker doesnt receive any information of the client after a while. Pausing and resuming, fixes the problem for some time. I tested multiple trackers, but all have same problem.
The torrents doesnt show any errors in my client
From what i've read in some fora, is that i need to put active torrents in queu to -1 to go around the problem..; testing it now.

[flvinny521]

@Buitenlust I had read the same advice, but I already have my active torrents set to -1 and it has not helped.

[r13s]

@Buitenlust @flvinny521 Try to disable queue completely - unmark the "Torrent Queueing" checkbox. It's a temporary solution for me until problem persists.

[arvidn]

If that actually solves the problem, it's not at all obvious there is a bug at all. Basically, if the auto-manager (queuing logic) in libtorrent stops your torrent immediately as it completes, why is that wrong?

The logic will maximize your download rate, so if there is a queued torrent that needs downloading, it will prefer that. Otherwise it will optimize upload utility. It will start the torrent with the highest downloader/seed ratio. i.e. the torrent with the most need for another seed.

[r13s]

@arvidn Disabling queuing is not a complete solution for me. I have slow ADSL Internet access, so there is a need to limit the number of uploads and downloads. Otherwise, my network connection becomes unstable because of the hundreds of active tasks. Now with no queue management I have to start only some of them. Of course I can manually start and stop the tasks, but it is very inconvenient. I think the problem is not in the queuing logic, but in that there's no announcing of uploading tasks when queuing limits were set.

[arvidn]

this is with libtorrent 1.0.x, right?

[r13s]

Right, because in versions prior to 1.0.x option "Do not count slow torrents in these limits" didn't work for me (at least in 0.16.x) so enabled queuing was useless.

[arvidn]

I get the impression that the problem happens when there are more than 1600 active torrents because qBT is not setting the active_tracker_limit to the active_limit value. (these settings are new in libtorrent 1.0 and not documented under the queuing section). See this post:

qbittorrent/qBittorrent#3473 (comment)

[r13s]

I have less than 1600 torrents.

[r13s]

@arvidn A value of -1 is valid for the active_dht_limit, active_tracker_limit and active_lsd_limit or it needs to be set to 2147483647 instead, as stated there?

[arvidn]

-1 means "infinite" for all of those limits. See:

https://github.com/arvidn/libtorrent/blob/RC_1_0/src/session_impl.cpp#L4331

[arvidn]

fixed here: 57f22b6