mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
Peer relevance is sometimes more than 100% #16895
Labels
No labels
Accessibility
AppImage
Bounty
Build system
CI
Can't reproduce
Code cleanup
Confirmed bug
Confirmed bug
Core
Crash
Data loss
Discussion
Docker
Documentation
Duplicate
Feature
Feature request
Feature request
Feature request
Filters
Flatpak
GUI
Has workaround
I2P
Invalid
Libtorrent
Look and feel
Meta
NSIS
Network
Not an issue
OS: *BSD
OS: Linux
OS: Windows
OS: macOS
PPA
Performance
Project management
Proxy/VPN
Qt bugs
Qt6 compat
RSS
Search engine
Security
Temp folder
Themes
Translations
Triggers
Waiting diagnosis
Waiting info
Waiting upstream
Waiting web implementation
Watched folders
WebAPI
WebUI
autoCloseOldIssue
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/qBittorrent#16895
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Steps to reproduce
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.
@xavier2k6 commented on GitHub (May 25, 2025):
@chrisfosterelli Do you only observe qBittorrent (peers) exhibiting that behavior?
@chrisfosterelli commented on GitHub (May 27, 2025):
Interesting question... going to try another download and will let you know!
@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.
@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
@xavier2k6 commented on GitHub (Aug 27, 2025):
Confirmed with latest master commit & latest libtorrent RC_2_0 commit: (Main GUI)
@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.