Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wrong uploaded data statistics shown when using I2P #22159

Open
absolutep opened this issue Jan 13, 2025 · 8 comments
Open

Wrong uploaded data statistics shown when using I2P #22159

absolutep opened this issue Jan 13, 2025 · 8 comments
Labels

Comments

@absolutep
Copy link

absolutep commented Jan 13, 2025

qBittorrent & operating system versions

Qt: 6.8.0
Libtorrent: 2.0.10.0
Boost: 1.86.0
OpenSSL: 3.4.0
zlib: 1.3.1
qBittorrent v5.1.0beta1 (64-bit)
Windows 10

What is the problem?

Wrong statistics in uploaded data is shown when using qBittorrent with I2P.

Here, as shown in the screenshot - I am the only seeder and a person is downloading is only downloader.

At, 16.4% total uploaded data should come close to 3.28GB [out of 20GB] but here it is only shown as 1.21GB.

1

Steps to reproduce

  1. Upload any I2P torrent
  2. let it be downloaded
  3. check uploaded stats
  4. uploaded numbers [in GB] do not match the percentage of file transferred

Additional context

  1. This is not a multiple day statistics. This is statistics from today only.
  2. I pulled all nighter at work and qBittorrent was in background running - restarted qBittorrent in the morning, cause I restarted I2P router.
  3. The following message "UPnP/NAT-PMP port mapping failed" has no bearing on my torrenting experience.
  4. The statistics displayed when using only Clearnet torrenting has no discrepancies whatsoever.

Log(s) & preferences file(s)

13-01-2025 10:33 AM - UPnP/NAT-PMP port mapping failed. Message: "could not map port using UPnP[]: no router found"
13-01-2025 10:33 AM - UPnP/NAT-PMP port mapping failed. Message: "could not map port using UPnP[]: no router found"
13-01-2025 10:31 AM - Detected external IP. IP: ""
13-01-2025 10:31 AM - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Jan 1 07:52:30 2025.
13-01-2025 10:31 AM - Successfully listening on IP. IP: "::1". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "::1". Port: "TCP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "fe80::3-:44b1%8". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "fe80::3-:44b1%8". Port: "TCP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "127.0.0.1". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "127.0.0.1". Port: "TCP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "". Port: "TCP/"
13-01-2025 10:31 AM - UPnP/NAT-PMP support: ON
13-01-2025 10:31 AM - Encryption support: ON
13-01-2025 10:31 AM - Anonymous mode: OFF
13-01-2025 10:31 AM - Peer Exchange (PeX) support: ON
13-01-2025 10:31 AM - Local Peer Discovery support: ON
13-01-2025 10:31 AM - Distributed Hash Table (DHT) support: ON
13-01-2025 10:31 AM - HTTP User-Agent: "qBittorrent/5.1.0beta1"
13-01-2025 10:31 AM - Peer ID: "-qB5100-"
13-01-2025 10:31 AM - Trying to listen on the following list of IP addresses: "0.0.0.0:,[::]:"
13-01-2025 10:31 AM - Using config directory: C:\Users\AppData\Roaming\qBittorrent
13-01-2025 10:31 AM - qBittorrent v5.1.0beta1 started. Process ID: 3968

@xavier2k6 xavier2k6 added the I2P label Jan 13, 2025
@thalieht
Copy link
Contributor

thalieht commented Jan 13, 2025

I am the only seeder and a person is downloading is only downloader.

This is a private torrent right? Otherwise how can you be sure that you're the only seeder.

restarted qBittorrent in the morning

I don't think peer stats (total_upload, total_download) survive qBt restarts.

@absolutep
Copy link
Author

yes, it is private.

I think maybe qBittorrent is adding Overhead data [being relay node etc.]

I will add more details if and when I see some more discrepancies.

@anikey-from-i2p
Copy link

being relay node etc

But qBittorrent is not being a relay node. The relay node here is i2p. qBittorrent does not know anything about the amount of data relayed by i2p.

@absolutep
Copy link
Author

Well, look at his @thalieht @anikey-from-i2p

Torrent itself is of 4.28 GB, how can it transfer 5.5 GB? More than 100% of the pieces?

I made this torrent and kept it seeding overnight.

Image

@thalieht
Copy link
Contributor

Torrent itself is of 4.28 GB, how can it transfer 5.5 GB? More than 100% of the pieces?

I don't really know anything about I2P but from what i've read it uses other peers as proxies. You delivered 5.5 GiB but did the peers successfully deliver them to the intended recipient? Just a guess...

Unlike Tor onion routing, I2P uses so-called garlic routing. This divides your message into smaller messages, called cloves. These are all encrypted and travel separately until their destinations.

Maybe one of those "cloves" gets lost making the rest of the "cloves" useless.
Again, i don't know anything about I2P and all these could be nonsense.

@anikey-from-i2p
Copy link

anikey-from-i2p commented Jan 25, 2025

Data delivery reliability is handled at the I2P router, AFAIK.

By the way, I think I noticed this problem half a year ago: https://i2pforum.net/viewtopic.php?t=1289

Back then, I thought it was that I2PSnark downloaded some things twice for some reason. Maybe someone can test this bug but without Snarks? (Like, a simulation where there are only qBT peers)

How i think this could happen is that Snark requests the same piece from two different peers (my hypothetical guess): first from one peer, but then it takes some time (because i2p can lag sometimes) and then from the second peer, and then they both send the same data.

@Neustradamus
Copy link

@arvidn has done a recent PR about I2P:

@absolutep
Copy link
Author

Data delivery reliability is handled at the I2P router, AFAIK.

By the way, I think I noticed this problem half a year ago: https://i2pforum.net/viewtopic.php?t=1289

Back then, I thought it was that I2PSnark downloaded some things twice for some reason. Maybe someone can test this bug but without Snarks? (Like, a simulation where there are only qBT peers)

How i think this could happen is that Snark requests the same piece from two different peers (my hypothetical guess): first from one peer, but then it takes some time (because i2p can lag sometimes) and then from the second peer, and then they both send the same data.

Yes, problem is similar, actually I noticed it only once during lockdown era in BiglyBT but that was not much of an issue at that time, and then I do not know how but BiglyBT upload statistics regarding I2P has been pretty much accurate.
I mean this was the main reason for me to notice this discrepancy in qBittorrent cause BiglyBT never falters in this regard.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants