starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

Incorrect Seeds / Peers for some tracker(s). #16710

New issue

Open

opened 2026-02-22 03:21:18 -05:00 by deekerman · 8 comments

deekerman commented

2026-02-22 03:21:18 -05:00

Owner

Originally created by @bretter on GitHub (Mar 13, 2025).

qBittorrent & operating system versions

qbittorrent: 5.0.4
OS: Arch Linux (current)
libtorrent-rasterbar: 2.0.11

What is the problem?

qBittorrent mis-identifies large numbers of seeders as peers for torrents downloaded from hdbits, showing significantly lower seed counts and higher peer counts than the site's peer list or other torrent clients.

As an example, one torrent downloaded from hdbits shows the following seeds and peers:
qBittorrent: Seeds = 10 | Peers = 83
Transmission: Seeds = 48 | Peers = 1
Site's Peer List: Seeds = Seeds 49 | Peers = 1

The problem with this mis-identification is that qBittorrent will activate connections with these peers, resulting in hundreds of active peer connections which are actually seeder-to-seeder connections. Even when no bandwidth is being used, these active connections increase cpu utilization substantially compared to when torrents from that tracker are stopped.

Steps to reproduce

Download and start any torrent from hdbits
Compare seed / peer counts reported by qbittorrent to the site's reported peers or reported peers for the same torrent in another client

Additional context

I spent some time capturing packets via tcpdump and wasn't able to learn much except that hdbits seems to be the only tracker among the trackers I use that uses the bittorrent scrape convention. This was evidenced by a plaintext get request to their scrape url.

For all other trackers I'm using qBittorrent reports seed / peer numbers that are consistent with their respective websites and other clients.

Log(s) & preferences file(s)

happy to provide any relevant logs / preferences upon request

Originally created by @bretter on GitHub (Mar 13, 2025). ### qBittorrent & operating system versions qbittorrent: 5.0.4 OS: Arch Linux (current) libtorrent-rasterbar: 2.0.11 ### What is the problem? qBittorrent mis-identifies large numbers of seeders as peers for torrents downloaded from hdbits, showing significantly lower seed counts and higher peer counts than the site's peer list or other torrent clients. As an example, one torrent downloaded from hdbits shows the following seeds and peers: qBittorrent: Seeds = 10 | Peers = 83 Transmission: Seeds = 48 | Peers = 1 Site's Peer List: Seeds = Seeds 49 | Peers = 1 The problem with this mis-identification is that qBittorrent will activate connections with these peers, resulting in hundreds of active peer connections which are actually seeder-to-seeder connections. Even when no bandwidth is being used, these active connections increase cpu utilization substantially compared to when torrents from that tracker are stopped. ### Steps to reproduce 1. Download and start any torrent from hdbits 2. Compare seed / peer counts reported by qbittorrent to the site's reported peers or reported peers for the same torrent in another client ### Additional context I spent some time capturing packets via tcpdump and wasn't able to learn much except that hdbits seems to be the only tracker among the trackers I use that uses the [bittorrent scrape convention](https://wiki.theory.org/BitTorrentSpecification#Tracker_.27scrape.27_Convention). This was evidenced by a plaintext get request to their scrape url. For all other trackers I'm using qBittorrent reports seed / peer numbers that are consistent with their respective websites and other clients. ### Log(s) & preferences file(s) happy to provide any relevant logs / preferences upon request

deekerman added the

Waiting upstream

Libtorrent

labels

2026-02-22 03:21:18 -05:00

deekerman commented

2026-02-22 03:21:22 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Mar 14, 2025):

The problem with this mis-identification is that qBittorrent will activate connections with these peers, resulting in hundreds of active peer connections which are actually seeder-to-seeder connections.

That's unavoidable in any case. Scrape only provides counters, it does not carry information about individual peers.
The tracker request itself also does not provide any info about peers beside their IP address and port. So the client must connect to every peer to learn who is who, there is no way around that.

these active connections increase cpu utilization substantially compared to when torrents from that tracker are stopped.

There is a tunable in Settings > Advanced called Outgoing connections per second. You could set it to some acceptable number for you, or even to 0 to prevent any outgoing connections.

@HanabishiRecca commented on GitHub (Mar 14, 2025): > The problem with this mis-identification is that qBittorrent will activate connections with these peers, resulting in hundreds of active peer connections which are actually seeder-to-seeder connections. That's unavoidable in any case. Scrape only provides counters, it does not carry information about individual peers. The tracker request itself also does not provide any info about peers beside their IP address and port. So the client must connect to every peer to learn who is who, there is no way around that. > these active connections increase cpu utilization substantially compared to when torrents from that tracker are stopped. There is a tunable in `Settings` > `Advanced` called `Outgoing connections per second`. You could set it to some acceptable number for you, or even to `0` to prevent any outgoing connections.

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@stalkerok commented on GitHub (Mar 14, 2025):

The tracker only provides a list of peers with no seeds/leechers separation, unfortunately qBittorrent (libtorrent) can't properly identify who is who and this is a really issue.

@stalkerok commented on GitHub (Mar 14, 2025): The tracker only provides a list of peers with no seeds/leechers separation, unfortunately qBittorrent (libtorrent) can't properly identify who is who and this is a really issue.

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@bretter commented on GitHub (Mar 14, 2025):

Thanks for the input @stalkerok, @HanabishiRecca

Is there a good way to capture the list of individual peers reported by the tracker and the seed / peer counts as captured during the scrape?

It seems like there might be two issues here:

libtorrent's inability to distinguish between seeds / peers, and
more peers detected than reported by the tracker (not expected on a private tracker).

I'd like to confirm what the tracker is reporting to better understand if (2) might be bad data from the tracker itself.

@bretter commented on GitHub (Mar 14, 2025): Thanks for the input @stalkerok, @HanabishiRecca Is there a good way to capture the list of individual peers reported by the tracker and the seed / peer counts as captured during the scrape? It seems like there might be two issues here: 1. libtorrent's inability to distinguish between seeds / peers, and 2. more peers detected than reported by the tracker (not expected on a private tracker). I'd like to confirm what the tracker is reporting to better understand if (2) might be bad data from the tracker itself.

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@stalkerok commented on GitHub (Mar 14, 2025):

This issue is not only related to private trackers, it is more global. The inability of qBittorrent (libtorrent) to adequately determine the number of seeds on its own, without relying on tracker data (the case when the tracker provides incorrect peers/seeds/leechers data), makes it very difficult to manage torrents, because the actual number of seeds in the swarm is very different from the values in the columns in the transfer list.

I have already written about this many times.

@stalkerok commented on GitHub (Mar 14, 2025): This issue is not only related to private trackers, it is more global. The inability of qBittorrent (libtorrent) to adequately determine the number of seeds on its own, without relying on tracker data (the case when the tracker provides incorrect peers/seeds/leechers data), makes it very difficult to manage torrents, because the actual number of seeds in the swarm is very different from the values in the columns in the transfer list. I have already written about this many times.

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@HanabishiRecca commented on GitHub (Mar 14, 2025):

Is there a good way to capture the list of individual peers reported by the tracker and the seed / peer counts as captured during the scrape?

Use Wireshark instead of raw tcpdump. Capture with filter tcp port 80 (assuming that the tracker is http).

To understand responses read about peer list and scrape formats.

@HanabishiRecca commented on GitHub (Mar 14, 2025): > Is there a good way to capture the list of individual peers reported by the tracker and the seed / peer counts as captured during the scrape? Use Wireshark instead of raw tcpdump. [Capture](https://wiki.wireshark.org/CaptureFilters) with filter `tcp port 80` (assuming that the tracker is http). To understand responses read about [peer list](https://www.bittorrent.org/beps/bep_0023.html) and [scrape](https://www.bittorrent.org/beps/bep_0048.html) formats.

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@bretter commented on GitHub (Mar 14, 2025):

This issue seems to be captured in the libtorrent issue tracker here:
libtorrent 2.0.x is much too aggressive in retrying connections to known seeds

@bretter commented on GitHub (Mar 14, 2025): This issue seems to be captured in the libtorrent issue tracker here: [libtorrent 2.0.x is much too aggressive in retrying connections to known seeds](https://github.com/arvidn/libtorrent/issues/7700)

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@stalkerok commented on GitHub (Mar 14, 2025):

https://github.com/arvidn/libtorrent/issues/7444

@stalkerok commented on GitHub (Mar 14, 2025): https://github.com/arvidn/libtorrent/issues/7444

deekerman commented

2026-02-22 03:21:24 -05:00

Author

Owner

@reardonia commented on GitHub (Oct 28, 2025):

Yes, this is the same issue as libtorrent#7700. qBt+libtorrent is not "learning" about seeds. Even though the peer communicates that it is "upload_only" peer, aka seed, qBt (as seed) will keep contacting that peer.

@reardonia commented on GitHub (Oct 28, 2025): Yes, this is the same issue as libtorrent#7700. qBt+libtorrent is not "learning" about seeds. Even though the peer communicates that it is "upload_only" peer, aka seed, qBt (as seed) will keep contacting that peer.