qBittorrent v3.3.12, Win7 x64 SP1

qB reports an incorrect amount of seeders and leechers for many torrents on several private trackers. If I open the torrent status from the tracker site's webpage, I often see quite a lot more peers than what qB shows. For example, one torrent shows on the site that it has 7 seeds (me included) but qB shows zero.

Also the scraping of paused torrents shows incorrect information. Many times there are no reported seeds at all. This makes it difficult to determine which torrent to download next as diskspace becomes available.

Could this be a duplicate of #5569?

It seems like the same issue. #5569 was closed because it should have been fixed but I do see the same problem with the latest version. For example, I now have 50 stopped (non-complete) torrents which show zero seeds and peers.

Are we sure that it is a client issue?

The tracker lags behind have wrong data usually, it is usually just a rough estimate of how many peers are there but it is never accurate. It is mostly used for sorting on sites but no one should rely on them. There IS a tracker interface, but regular peers and users cannot access that. Basically, you can list the peers for each torrent directly from the tracker software, this is useful for tracker staff. (Of course, not every tracker software has this.)

@Boulder08 Can you check with a different client, and post screenshots for a public torrent for example? Or something that we can start out from?
Thank you!

Based on my tests, uTorrent works up to v3.0 build 26473. Anything after that has the exact same issue with the display. I'm currently using v2.2.1 because of this issue and the number of seeds has been fairly accurate all the time. I tend to download things with something like less than 5 seeders to make sure I'm able to finish them before they die. There has always been almost the same number of clients to connect to when starting the download.

There are some private trackers where the 'non-downloading scraping' works. On some it clearly doesn't.

This is what I see in qBT for this torrent: http://torrent.unix-ag.uni-kl.de/torrents/KNOPPIX_V7.7.1DVD-2016-10-22-EN.torrent (http://torrent.unix-ag.uni-kl.de/)

This is what uTorrent v2.2.1 shows:

Both are without me starting the download. In qBT, I had to use Force recheck to get the client to scrape. Right now the webpage holding the torrent file shows 291 seeds and 9 leechers.

Up until 4.1.2 there was a visual bug that showed 0 seeds/peers whether it was actually 0 or there was no tracker scrape. Now it shows N/A if there is no scrape.
I guess this issue is solved.

This one is not yet resolved, to me it looks the exact same with v4.1.2.

I know at least one tracker where the amount of seeds or peers is usually zero also for torrents in seeding.

And what does the tracker list show? If it's a private torrent (no PeX, DHT, LSD) and it shows N/A qbt didn't receive scrape. What do you expect it to show?

The tracker list shows that it's working but 0 seeds and peers.

As I've written earlier, uTorrent gets it right up until v3.0 build 26473. Too bad it's closed source so it's not possible to see what has really changed in the next build.

This still happens for me on qBT v4.1.3 -- I get persistent 'seed' connections on seeding torrents that have 100% of all the files.
None of the 'seeds' show up as 100% in the peers tab though!

I posted this in the libtorrent ticket I opened. It looks like in this case qBt is doing something wrong because the numbers are in the correct range but displayed incorrectly in the torrent list. However, those torrents with zero values don't have any numbers anywhere so it's something slightly different and probably libtorrent-related.

This is what qBt shows for a common test torrent, a Knoppix image:

This is what the tracker list shows:

And this is what the truth is:

You're still using 4.1.2 -.- in 4.1.3 it shows that that tracker didn't send a scrape!

I may have used the phrase 'up until' wrongly but i meant 4.1.2 INCLUDED has that bug.

Yes, 'up until' is what confused me here. I'll switch to testing 4.1.3 as soon as the trackers I use allow it (some of them whitelist clients version by version).

However, it doesn't explain why a very old uTorrent version works fine. Have there been some changes in scraping protocol-wise in recent years? Also, paused torrents don't seem to be scraped at all even though the client has been running for a long time, is this intentional?

Have there been some changes in scraping protocol-wise in recent years?

That's a question for libtorrent as qBt just shows what it provides :). Maybe the tracker is configured to send that data only to utorrent 2.2.1? Who knows.

Also, paused torrents don't seem to be scraped at all even though the client has been running for a long time, is this intentional?

I assume so. Is there a reason a paused torrent should be scraped? Paused means there is no intention to seed or receive so why would it announce.

I assume so. Is there a reason a paused torrent should be scraped? Paused means there is no intention to seed or receive so why would it announce.

Well, to see if some torrent is about to die due to lack of seeds and should be downloaded. Currently I have about 50 torrents waiting, I'll pick them along the way when I get more HDD space and start with torrents with the less amount of seeds. Doing that, I also help keep the torrents alive longer.

Basically it would be a nice option to be able to scrape manually, there's no need to do that constantly for paused torrents.

Have there been some changes in scraping protocol-wise in recent years?

That's a question for libtorrent as qBt just shows what it provides :). Maybe the tracker is configured to send that data only to utorrent 2.2.1? Who knows.

arvidn asked in the libtorrent ticket about which libtorrent call which returned the wrong values. Can you help me with that? I thought that there was only one way to scrape data from the tracker.

Seeds = scrape_complete;
Peers = scrape_incomplete;
Downloaded = scrape_downloaded;

In the torrent list the number in the parentheses is apparently the same for Seeds/Peers (we don't add the peers together from several trackers as you can see) and the number outside is the number of connected peers which can be from any tracker or DHT etc.

But don't forget to mention that qBt doesn't differentiate between no scrape and 0 peers/seeds i.e. it shows 0 for both cases in the qBt version you're using. Don't lead him in a wild goose chase based on invalid info.

As instructed by arvid, I've been wiresharking the packets a bit.

Does qBt just use the announce.php script to talk to the tracker? I noticed that uTorrent apparently uses both announce.php and scrape.php. In those zero number cases, scrape.php will give uTorrent the data it needs.

Does qBt just use the announce.php script to talk to the tracker? I noticed that uTorrent apparently uses both announce.php and scrape.php.

Sorry i don't know.

Basically it would be a nice option to be able to scrape manually, there's no need to do that constantly for paused torrents.

qBt doesn't check if a torrent is paused when re-announcing so this must be forbidden in libtorrent.

Basically it would be a nice option to be able to scrape manually

Actually i found https://libtorrent.org/reference-Core.html#scrape_tracker() which qBt doesn't use anywhere. qBt only re-announces. TBH i'm not familiar with this stuff.

You should make a new issue if you want it.

You're still using 4.1.2 -.- in 4.1.3 it shows that that tracker didn't send a scrape!

I may have used the phrase 'up until' wrongly but i meant 4.1.2 INCLUDED has that bug.

I tested v4.1.3 now, but it seems to have some problem.

The torrent in question is queueing at the moment of the screenshots.

If there is no scrape from tracker, the seeds/peers in the transferlist show seeds/peers from DHT/PeX etc.

None of those are available as it's a private torrent. Also visible in the screenshot that the amount of those is zero, the top three lines.

The counters used from libtorrent, have this explanation.

and qBt uses them this way (shown in transferlist and General tab in the parentheses).

Basically if there is no scrape use list_seeds/list_peers which i suppose must be cached somewhere?
I also notice here that there is the same bug as in the trackerlist where it doesn't distinguish between 0 and no scrape (no scrape is -1) BUT maybe this was intentional to show that the torrent is not dead if there are seeds/peers from DHT/PeX but none in tracker scrape?