qbittorrent seeding not reported to tracker

[cpscooter]

qBittorrent 3.2.1
My new torrents are seeding and uploading, yet they are listed as hit and run torrents by the host. I have checked with some port check tool sites, and they report that my port is visible and port forwarding is working.
The site support gurus say that my client (qbittorrent) is seeding fine, but the seeding is not being reported. I then tried pausing the torrents and starting them again. This immediately took them off the hit and run list.
I tried raising my connection limits to higher and higher numbers (currently at 1000, 500, 500, 500)
I have a static port so I can forward it. Use different port on each startup is not checked.
Use UPnP / NAT-PMP is checked.
No speed limits are checked.
Anonymous mode is not checked.
Torrent queueing is checked and set to 5, 7, 12.
I have not changed any advanced settings.

[ngosang]

they are listed as hit and run torrents by the host

The only reason for that is qBittorrent is not reannouncing to the trackers each 30 minutes but I never see this problem before.

[cpscooter]

Is there something I can try on my end or is this a bug?

[ngosang]

As you using Windows? If yes you can try the v3.3.0 alpha build https://qbforums.shiki.hu/index.php/topic,3606.0.html

[cpscooter]

How stable is 3.3.0 alpha? I don't want to throw oil on the fire. And do you have documentation that this issue has been addressed in this release?

[ngosang]

I think is stable enough. Many things changed and the forum binaries were built with a more updated libtorrent version.

[cpscooter]

Funny, all I have to do to get rid of all my hnr is to pause and restart those torrents. Could this behavior help the developers to figure out how to reproduce the problem and fix it?
P.S. I will try the alpha as soon as I have time.

[ghost]

The problem is gone when I unchecked "Don't count slow torrents" checkbox - now active tasks reannounces correctly.
qBittorrent 3.2.1

[cpscooter]

Did you mean in the BitTorrent settings page, "Do not count slow torrents in these limits"?
I checked that box, but the problem is still there. I think I'll try the alpha suggested by ngosang next.

[cpscooter]

OK I upgraded to 3.3.0. I already see an issue. All Added On dates are 12/31/1969 4pm. Good date, the Grateful Dead played at Boston Tea Party. You can stream the show. But what does that have to do with this thread? And has this issue already been addressed?

[ngosang]

All Added On dates are 12/31/1969 4pm.

@cpscooter could you try to add a new torrent and look at the Added On date? If the date is right the problem is in the code that imports the old fast-resume format.

[cpscooter]

So far after upgrading to 3.3.0 my trackers all say
Status: Not working
Peers: 0
Message: Out of date or Banned client version. You need to change your client. Please check the Accepted clients list.
Is this an issue with the site listed under URL or is this a bug? More importantly, Is there a workaround?

[ngosang]

Answer my question #3473 (comment) first.

So far after upgrading to 3.3.0 my trackers all say

This only happens in some private trackers. It's because the User-Agent is qBittorrent v3.3.0alpha and they detect the alpha word as a modified client. It's not a bug but you have to wait to the stable version.

[sledgehammer999]

Try using v3.2.3 which uses an updated libtorrent. To downgrade somewhat safely from v3.3.0:

1. Close qbt and wait until it dissapears from the "processes" list in Task Manager
2. Go to your BT_backup folder and rename all the <infohash>.fastresume.<number> files to <infohash>.fastresume
3. Start qbt. It should start your torrents without problems.

Of course you should backup the BT_backup folder before doing the above, so can revert to it if it fails.
Does v3.2.3 continue to show as hit-n-run on your trackers? If yes, how many torrents do you have seeding? 7?

[cpscooter]

OK I'm back on v3.2.3. Announcing to tracker does not work. I have 13 hnr now. 77 torrents. 77 seeding. I can pause the 13 that are hnr. They all pause at once, as compared to version 3.3.0 where they only pause one at a time even if all 13 are selected. I can start them all at once, and they queue and soon seed. This announce and my hnr goes to zero. I soon build up a nasty long list of hnr. Is this an isolated case or is everyone having this problem? Could DHT or PeX have anything to do with this?

[cpscooter]

Current settings:
DHT: off
PeX: off
Local peer discovery: on
Anonymous mode: off
Max downloads: 5
Max uploads: 7
Max active: 12
Do not count slow torrents in these limits: on
no see ratio limits set.

Incoming port: 30002, and it checks OK.
Global Max Connections: 1000
Max Connections per torrent: 500
Global Max Updated slots: 500
Max Uploaded slots per torrent: 500

Advanced options are all at default settings.

[cpscooter]

3.2.3 still not announcing to tracker. I'm manually pausing and starting the torrents to keep them out of hnr. Can this be escallated? I would like to stay with qbt....

[sledgehammer999]

@arvidn It seems that 1.0.6 doesn't announce to trackers. It seems to anounce only when paused. This results in hit-n-run stats from the tracker to the user profile. Can you tell him what to test? OR maybe you can look at your sources?
(I haven't confirmed anything, since I am not a member of any private tracker).
Plus, I'll probably be out of my building computer for almost 2 weeks so I won't be able to provide patched builds to test.

[sledgehammer999]

@cpscooter Can you test 1 torrent with another client to see if it works and to rule out a connection problem?

[cpscooter]

@sledgehammer999 Yes I still have uTorrent. I have tried a few torrents and they work flawlessly in uTorrent in spite of all the advertisements. Thank you for addressing this.

[arvidn]

wireshark dumps of the announces would be great (even if it's just to confirm that the initial announce work and there literally is no other announce until pause). I take this report to mean that the in-between (between starting and stopping) a torrent does not work.

[Gelmir]

I'm currently trying to reproduce this on local network using qBt embedded
tracker.
So far I can say this: pausing indeed does immediately report dl/ul amount
to tracker.

I need around 30 minutes to test my theory. Most probably cause is tracker
announce timer, which is respected. qBt has it at 30minutes. So, unless the
timer has expired nothing is reported. But this is just my theory.

чт, 6 авг. 2015 г. в 3:29, Arvid Norberg notifications@github.com:

wireshark dumps of the announces would be great (even if it's just to
confirm that the initial announce work and there literally is no other
announce until pause). I take this report to mean that the in-between
(between starting and stopping) a torrent does not work.

—
Reply to this email directly or view it on GitHub
#3473 (comment)
.

[Gelmir]

Guess my theory is right. Report was made after announce interval defined by tracker.

https://onedrive.live.com/redir?resid=5BF1AEB043747370!1043&authkey=!ANXc61mXQfrbjHY&ithint=file%2cpcapng

[cpscooter]

@Gelmir I see you found the cause. Will you please clarify whether this is a problem with qbt or with the tracker? What is the file you provided a link to on onedrive? Do I have a workaround? Thanks

[cpscooter]

Do you see anything in my settings (see above) that could cause the problem?

[Gelmir]

No, that's actually expected behavior. @arvidn may fix me on this, but I think I'm right.

When we first announce to tracker, the tracker sends back an announce interval (d8:intervali1800e5:peersld2:ip13:192.168.0.1874:porti2277eeee), which it assumes the client will respect (and we do). So we do not announce/report to tracker anything until this interval expires.

My guess is that your tracker may set announce interval to several hours, thus it may seem that no reports are made. Usually private trackers have this interval at 30-60 minutes.

[sledgehammer999]

My guess is that your tracker may set announce interval to several hours, thus it may seem that no reports are made. Usually private trackers have this interval at 30-60 minutes.

If that is true shouldn't the tracker, not report it as hit-n-run before the tracker's interval passes and we don't announce?
@cpscooter can does the "reannounce in" value in the general button (bottom of window) show as value?
Will you be able to provide to @arvidn wireshark dumps? I advice you to use only one active seeding torrent when capturing.

[cpscooter]

I am willing to try wireshark to help @arvidn pin this down. Perhaps tonight. But utorrent does not have this problem...what are they doing differently?
@sledgehammer999 the "reannounce in" value for the hnr torrents is 0 before pausing and resuming, then it goes to 59m. It looks like it counts down to 0 and then does not reset to 59m after reannouncing.

[cpscooter]

In fact most of my 77 torrents count down to 0 from various values like 14m, 29m, 59m and they all stay at 0 unless I manually pause and start. I'm not sure if it's all of them so I'll wait a few hours and see if all are 0.

[chrishirst]

But utorrent does not have this problem...what are they doing differently?

uTorrent does not use libtorrent, they have their own closed source bittorrent protocol engine.

[cpscooter]

@arvidn
Reporting seed status was my newbie way of saying "reannouncing".

[arvidn]

ah, right. I do see lots of "&left=0" in the wireshark dump bezdupel posted. How about the "seeding" aspect? Is this something that only affects seeds? Are downloading torrents being reannounced fine?

[flvinny521]

Personally, I've never had an issue with a downloading torrent. Only after the download has completed and I become a seeder.

[arvidn]

but that's maybe because failing to announce to the tracker isn't considered an issue (from your point of view). Or are you saying that you've looked, and you've never seen omitted announces for downloading torrents?

[flvinny521]

You're right, I have never checked. I am an end-user who is unfamiliar with the behind the scenes operation. I would have only known something was wrong if a download stalled or was unable to finish. As I said in the other thread, I'll be happy to test any of these scenarios and provide logs if there's anything you'd specifically like to try.

[sledgehammer999]

@cpscooter @flvinny521 @bezdupel and anyone else having the same problem:
Can you ask your private tracker operators how they determine "hit and run"? What are they looking for in the reannounce?
On answer to this will help @arvidn determine if libtorrent does the right thing.

[flvinny521]

I am sending PMs to the staff of all my private trackers. I will let you know what I hear.

EDIT: One of my trackers actually has an extensive thread about this very issue which I didn't see until I went to send a Staff PM and there was a link to it. The suggestion there was to turn off auto-managed for all torrents, and the users who have tried that report that it does work. I've just done the same for all my torrents and will check behavior in the next few days. However, I had previously set all my seed limits to -1 in an attempt to remove the auto-manage rules from impacting which torrents were active at any given time.

[r13s]

@sledgehammer999 @arvidn That's what they said (at the rutracker):
"If the client sends its announcement - corresponding torrent counted and displayed in your profile. Do not send - not taken into account. Unless of course the announcement complies."

[flvinny521]

From one of my well-known private trackers:

"What most clients continue to do (and is expected by most all private trackers) is that the client keep announcing using the typical announce interval they would while leeching. Otherwise the tracker can't know for sure that you are still there to seed and won't send your IP/port to leechers.

Generally, it's simply left=0 and if no data transfer occurs, then uploaded and downloaded will remain the same in each announce. If the client quits announcing, it times out from the swarm and is assumed to be gone/not a viable seed.

However, left should not be 0 if files are deselected and those files were not downloaded.
Likewise, an event=completed should not be sent if files are deselected.

Similar behavior occurs in Deluge due to a limit on the max number of actively announcing torrents see here: http://dev.deluge-torrent.org/ticket/2257

What is being described in those tickets, is HnRs being reported, which needs to be itemized down better for them. Check the "Seeding" column while looking at HnRs and see if it says "Seeding: Yes" if it doesn't say "Yes" then you aren't even announcing anymore.
If it says Seeding: Yes and still an HnR, then it's getting left>0 showing that you have some data remaining/deselected. (This is why you can never complete an HnR if you have deselected files, noted in the wiki)

Also note the "Last active" field, that is the date, in UTC, that your client last contacted the tracker regardless of what was sent. If it's more than an hour ago (compare to date on the bottom of the page) then your client isn't announcing it often enough and is effectively a dead peer."

I read the link and it seems that this could be the answer to the problem. It relates to the way libtorrent provides a default torrent count of 1600. It seems that Deluge can not override that limit, even if the user chooses a larger number.

For what it's worth, disabling the auto-managed option in Deluge has (so far) corrected the issue for me.

[arvidn]

the way the auto-manage logic in libtorrent works is by settings limits on how many torrents announce to the DHT, the trackers and local peer discovery and accept having any peers at all. Those are all separate limits. Let's say you have a million seeding torrents, there's a very low cost associated with allowing peers on a torrent (the hash table to find the torrent from its info hash will be larger the more torrents are allowed to have peers). The cost of announcing a torrent to the DHT is relatively high, contacting a tracker is relatively cheap.

When a torrent is auto-managed, it's subject to all these limits. If the active_tracker_limit is 1600 (which is the default) and you have 2000 torrents seeding, only 1600 of them will announce to the tracker. If you want all 2000 of them to announce, you have to set the active_tracker_limit to 2000. The same thing applies to if you want all of them to announce to local peer discovery (active_lsd_limit) and to announce to the dht (active_dht_limit).

It sounds like perhaps Deluge and qBittorrent are not setting these limits according what their users are expecting their behavior to be. This is documented here:

http://libtorrent.org/reference-Settings.html#active_tracker_limit

Looking at the documentation, I realize I need to update the "queuing" section to more explicit about this behavior too.

[sledgehammer999]

@arvidn we are setting active_tracker_limit, active_dht_limit and active_lsd_limit always to the same number as active_limit or -1 for unlimited. So I don't think this is the issue here.

[sledgehammer999]

@arvidn unless libtorrent has a bug and ignores those settings.
By the way, is anyone here that doesn't use qbittorrent on Windows? If yes, please state the libtorrent version used by your distro. (help->about->libraries)
EDIT: The windows version uses 1.0.x

[flvinny521]

Yes, I am using Deluge for Windows, libtorrent version 0.16.18.0.

Also, I have had all my 2500+ torrents seeding with auto-manage disabled for the last 6 days. It had seemed to fix the issue, but I just checked my torrents, and once again, nearly 1,000 of them were not reported as being seeded. I'm pausing and resuming all torrents now, which should force an announce, and then I'll check tomorrow to see if they're still seeding.

[sledgehammer999]

@flvinny521 this thread is for qbittorrent. As I said here it uses some additional settings that deluge might not set.

[flvinny521]

I'm aware that I'm on your git, but when it seemed like this thread had stalled a month ago I asked @arvidn to come take a look again since we seemed to be experiencing the same issues. Just wanted to provide my two cents since it seems to be the most active discussion on the subject. I'll happily move to qBittorrent if this gets resolved and your UI is snappier with a large number of torrents ☺.

[r13s]

Tested qBittorrent (3.2.1, libtorrent 1.0.5) with queuing enabled at my Manjaro laptop - got same issues as in Windows.
[offtop]Can we hope that the functionality of Deluge's ltConfig plug-in will ever be implemented please?[/offtop] 😄

[r13s]

@sledgehammer999 @arvidn I got the answer to your question from nnm-club.me:

On the user announce, tracker runs the following procedure:

• if the passkey is not correct then return an error;
• if the specific peer_id (or prefix) is banned then return an error;
• if the info_hash is not registered on the forum+tracker then return an error;
• if reported download or upload values are too large then ban the client;
• calculate ul/dl speed using previous values;
• if the event is "stopped", then erase the peer from the list, else update the list to have actual values for this peer;
• update the timestamps for timeout handlers;
• queue tracker state updates;

Once the global free leech flag is disabled, there are more checks involved, basically checking that the ratio is not too low and number of simultaneously downloading files is not too high.

We do not implement some specific "hit and run" detection routines in real-time. There is an offline periodic consistency check, that verifies if the user is cheating.

[r13s]

@sledgehammer999 Can we get a test build with values active_tracker_limit, active_dht_limit and active_lsd_limit set to -1, regardless of on or off queue management? Because in Deluge with queueing enabled if I set active_tracker_limit, active_dht_limit and active_lsd_limit to the same number as active_limit, I got the same issues, which stated here. But when I set active_tracker_limit, active_dht_limit and active_lsd_limit to -1 (or 2147483647), all works as expected without any issues.

[Grenaid]

Wow, was quite glad to finally find this thread. Couldn't seem to get help anywhere. Happy to help with debugging if needed, but for now, -1 worked like a charm. Finally, I can quit the pause/resume nonsense!

If it helps, I tried to run through the issue here:

https://qbforums.shiki.hu/index.php/topic,3525.0.html

[sledgehammer999]

@bezdupel here is a patched v3.2.3 build that sets to -1 the mentioned fields.

Patch included in the 7z. Paste here for convenience:

diff --git a/src/core/qtlibtorrent/qbtsession.cpp b/src/core/qtlibtorrent/qbtsession.cpp
index 2833198..85661d0 100644
--- a/src/core/qtlibtorrent/qbtsession.cpp
+++ b/src/core/qtlibtorrent/qbtsession.cpp
@@ -449,23 +449,17 @@ void QBtSession::configureSession() {
     if (pref->isQueueingSystemEnabled()) {
         int max_downloading = pref->getMaxActiveDownloads();
         int max_active = pref->getMaxActiveTorrents();
+
         if (max_downloading > -1)
             sessionSettings.active_downloads = max_downloading + HiddenData::getDownloadingSize();
         else
             sessionSettings.active_downloads = max_downloading;
-        if (max_active > -1) {
-            int limit = max_active + HiddenData::getDownloadingSize();
-            sessionSettings.active_limit = limit;
-            sessionSettings.active_tracker_limit = limit;
-            sessionSettings.active_dht_limit = limit;
-            sessionSettings.active_lsd_limit = limit;
-        }
-        else {
+
+        if (max_active > -1)
+            sessionSettings.active_limit = max_active + HiddenData::getDownloadingSize();
+        else
             sessionSettings.active_limit = max_active;
-            sessionSettings.active_tracker_limit = max_active;
-            sessionSettings.active_dht_limit = max_active;
-            sessionSettings.active_lsd_limit = max_active;
-        }
+
         sessionSettings.active_seeds = pref->getMaxActiveUploads();
         sessionSettings.dont_count_slow_torrents = pref->ignoreSlowTorrentsForQueueing();
         setQueueingEnabled(true);
@@ -473,11 +467,11 @@ void QBtSession::configureSession() {
         sessionSettings.active_downloads = -1;
         sessionSettings.active_seeds = -1;
         sessionSettings.active_limit = -1;
-        sessionSettings.active_tracker_limit = -1;
-        sessionSettings.active_dht_limit = -1;
-        sessionSettings.active_lsd_limit = -1;
         setQueueingEnabled(false);
     }
+    sessionSettings.active_tracker_limit = -1;
+    sessionSettings.active_dht_limit = -1;
+    sessionSettings.active_lsd_limit = -1;
     // Outgoing ports
     sessionSettings.outgoing_ports = std::make_pair(pref->outgoingPortsMin(), pref->outgoingPortsMax());
     // Ignore limits on LAN

[r13s]

@sledgehammer999 With this build #3473 is fixed for me 😄 Thanks.

[cpscooter]

@sledgehammer999,

This looks like it gets to the heart of the matter.

Just an observation:

I understand that a value of -1 means no limit is specified, so the > -1 test means that there is a limit.

However, I would question anyone who puts in a value of zero for any limit. This might mean no limit to them, but that would be a mistake.

Would it hurt to test for greater than zero instead of > -1?

From: sledgehammer999 [mailto:notifications@github.com]
Sent: Sunday, September 13, 2015 6:26 PM
To: qbittorrent/qBittorrent
Cc: cpscooter
Subject: Re: [qBittorrent] qbittorrent seeding not reported to tracker (#3473)

@bezdupel https://github.com/bezdupel here http://builds.shiki.hu/temp/qbittorrent_3.2.3_patched_for_issue_3473.7z is a patched v3.2.3 build that sets to -1 the mentioned fields.

Patch included in the 7z. Paste here for convenience:

diff --git a/src/core/qtlibtorrent/qbtsession.cpp b/src/core/qtlibtorrent/qbtsession.cpp
index 2833198..85661d0 100644
--- a/src/core/qtlibtorrent/qbtsession.cpp
+++ b/src/core/qtlibtorrent/qbtsession.cpp
@@ -449,23 +449,17 @@ void QBtSession::configureSession() {
if (pref->isQueueingSystemEnabled()) {
int max_downloading = pref->getMaxActiveDownloads();
int max_active = pref->getMaxActiveTorrents();
+
if (max_downloading > -1)
sessionSettings.active_downloads = max_downloading + HiddenData::getDownloadingSize();
else
sessionSettings.active_downloads = max_downloading;

•    if (max_active > -1) {
  

•        int limit = max_active + HiddenData::getDownloadingSize();
  

•        sessionSettings.active_limit = limit;
  

•        sessionSettings.active_tracker_limit = limit;
  

•        sessionSettings.active_dht_limit = limit;
  

•        sessionSettings.active_lsd_limit = limit;
  

•    }
  

•    else {
  

•    if (max_active > -1)
  

•        sessionSettings.active_limit = max_active + HiddenData::getDownloadingSize();
  

•    else
       sessionSettings.active_limit = max_active;
  

•        sessionSettings.active_tracker_limit = max_active;
  

•        sessionSettings.active_dht_limit = max_active;
  

•        sessionSettings.active_lsd_limit = max_active;
  

•    }
  

  • sessionSettings.active_seeds = pref->getMaxActiveUploads();
    sessionSettings.dont_count_slow_torrents = pref->ignoreSlowTorrentsForQueueing();
    setQueueingEnabled(true);
    @@ -473,11 +467,11 @@ void QBtSession::configureSession() {
    sessionSettings.active_downloads = -1;
    sessionSettings.active_seeds = -1;
    sessionSettings.active_limit = -1;

•    sessionSettings.active_tracker_limit = -1;
  

•    sessionSettings.active_dht_limit = -1;
  

•    sessionSettings.active_lsd_limit = -1;
   setQueueingEnabled(false);
  

  }
• sessionSettings.active_tracker_limit = -1;
• sessionSettings.active_dht_limit = -1;
• sessionSettings.active_lsd_limit = -1;
  // Outgoing ports
  sessionSettings.outgoing_ports = std::make_pair(pref->outgoingPortsMin(), pref->outgoingPortsMax());
  // Ignore limits on LAN

—
Reply to this email directly or view it on GitHub #3473 (comment) . https://github.com/notifications/beacon/AMzBopw-CCy38Z5FZM014UIk6FuFiCRRks5oxhm-gaJpZM4Fb9sg.gif

[sledgehammer999]

Actually I don't think there is a point into continuously adjusting the tracker/dht/lsd limits. I'll leave it unlimited for all cases. Tagging it for v3.2.4 so I won't forget.
@arvidn could it be that libtorrent has an "off by one" bug?

[arvidn]

bug fixed in libtorrent: arvidn/libtorrent@57f22b6

[sledgehammer999]

Thanks you all for contributing. Finally @arvidn was able to fix it. Nevertheless, these limits will always be set to unlimited with v3.2.4 and upwards.