Peer relevance is sometimes more than 100% #16895

Open
opened 2026-02-22 03:30:55 -05:00 by deekerman · 6 comments
Owner

Originally created by @chrisfosterelli on GitHub (May 21, 2025).

qBittorrent & operating system versions

qBittorrent: v5.1.0
Operating system: Debian (docker)
Qt: 6.8.2
Libtorrent: 2.0.11.0

What is the problem?

qBittorrent regularly shows peers with a relevance greater than 100%. This was originally reported here but was tangental to the original issue and that was closed. I see this too and was curious about it. This is in the web UI for what it's worth.

Image

Steps to reproduce

  1. Open web UI
  2. Download torrent
  3. Open peers tab
  4. Observe some peers have relevance greater than 100%

Additional context

It doesn't always seem to be the case, and I have difficultly establishing under what conditions it is. Perhaps notable is that the % seems to change up and down for that peer. So relevance might go from 100% -> 101.6% -> 100% -> 101% -> 100% through a series of updates from the same peer.

My understanding is that relevance represents the amount of blocks which you do not have that the peer does. If I understand correctly a number greater than 100% does not make sense.

Log(s) & preferences file(s)

I do not think these are necessary to reproduce but happy to provide if you feel useful.

Originally created by @chrisfosterelli on GitHub (May 21, 2025). ### qBittorrent & operating system versions qBittorrent: v5.1.0 Operating system: Debian (docker) Qt: 6.8.2 Libtorrent: 2.0.11.0 ### What is the problem? qBittorrent regularly shows peers with a relevance greater than 100%. This was originally reported [here](https://github.com/qbittorrent/qBittorrent/issues/18536#issuecomment-2641155715) but was tangental to the original issue and that was closed. I see this too and was curious about it. This is in the web UI for what it's worth. <img width="1100" alt="Image" src="https://github.com/user-attachments/assets/edeab88f-7041-484c-b040-6d91944540a4" /> ### Steps to reproduce 1. Open web UI 2. Download torrent 3. Open peers tab 4. Observe some peers have relevance greater than 100% ### Additional context It doesn't always seem to be the case, and I have difficultly establishing under what conditions it is. Perhaps notable is that the % seems to change up and down for that peer. So relevance might go from 100% -> 101.6% -> 100% -> 101% -> 100% through a series of updates from the same peer. My understanding is that relevance represents the amount of blocks which you do not have that the peer does. If I understand correctly a number greater than 100% does not make sense. ### Log(s) & preferences file(s) I do not think these are necessary to reproduce but happy to provide if you feel useful.
Author
Owner

@xavier2k6 commented on GitHub (May 25, 2025):

@chrisfosterelli Do you only observe qBittorrent (peers) exhibiting that behavior?

@xavier2k6 commented on GitHub (May 25, 2025): @chrisfosterelli Do you only observe qBittorrent (peers) exhibiting that behavior?
Author
Owner

@chrisfosterelli commented on GitHub (May 27, 2025):

Interesting question... going to try another download and will let you know!

@chrisfosterelli commented on GitHub (May 27, 2025): Interesting question... going to try another download and will let you know!
Author
Owner

@chrisfosterelli commented on GitHub (May 30, 2025):

@xavier2k6 So far in my testing I only observe qBittorrent peers exhibit this behaviour, as well as one client that just identified itself as "libtorrent 0.13.8". qBittorrent is very popular on my trackers so it's not impossible that other clients exhibit the same behaviour but that I missed it. It does not seem to affect every peer or even on every torrent.

@chrisfosterelli commented on GitHub (May 30, 2025): @xavier2k6 So far in my testing I only observe qBittorrent peers exhibit this behaviour, as well as one client that just identified itself as "libtorrent 0.13.8". qBittorrent is very popular on my trackers so it's not impossible that other clients exhibit the same behaviour but that I missed it. It does not seem to affect every peer or even on every torrent.
Author
Owner

@Robmonster commented on GitHub (Jun 3, 2025):

I have noticed this also, right now I have a 'Transmission 2.93' client reporting 105.2% relevance

@Robmonster commented on GitHub (Jun 3, 2025): I have noticed this also, right now I have a 'Transmission 2.93' client reporting 105.2% relevance
Author
Owner

@xavier2k6 commented on GitHub (Aug 27, 2025):

Confirmed with latest master commit & latest libtorrent RC_2_0 commit: (Main GUI)

Image
Image

@xavier2k6 commented on GitHub (Aug 27, 2025): Confirmed with latest master commit & latest libtorrent RC_2_0 commit: (Main GUI) ![Image](https://github.com/user-attachments/assets/e20d8647-f767-4d6d-acd3-39def6dfa7ab) ![Image](https://github.com/user-attachments/assets/b3ad216b-d990-4f92-bce6-b2f141b64541)
Author
Owner

@soyfrien commented on GitHub (Nov 8, 2025):

I only noticed this when I saw a bunch of seeds at 200%. But here's just a random download. It happens when selecting all or some of the files in a torrent for download.

Screenshot of the Peers tab in qBittorrent 5 on Windows shows Revelance can exceed 100%
qBittorrent: 5.1.0
Qt: 6.9.0
Libtorrent: 2.0.11.0
Boost: 1.86.0
OpenSSL: 3.5.0
zlib: 1.3.1
@soyfrien commented on GitHub (Nov 8, 2025): I only noticed this when I saw a bunch of seeds at 200%. But here's just a random download. It happens when selecting all or some of the files in a torrent for download. <img width="601" height="311" alt="Screenshot of the Peers tab in qBittorrent 5 on Windows shows Revelance can exceed 100%" src="https://github.com/user-attachments/assets/3da13a27-b6b9-44e4-8fef-5fa99e60636e" /> ``` qBittorrent: 5.1.0 Qt: 6.9.0 Libtorrent: 2.0.11.0 Boost: 1.86.0 OpenSSL: 3.5.0 zlib: 1.3.1 ```
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/qBittorrent#16895
No description provided.