-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Upload Issue in qBittorrent #13073
Comments
Please post settings and log files in plain text (https://github.com/qbittorrent/qBittorrent/wiki/Frequently-Asked-Questions#Where_does_qBittorrent_save_its_settings). A screenshot would also help. If the torrent is not private, can you also post it in a .zip here? |
The issue seems to be resolved after disabling uTP Protocol in Option > Connection . Although I can't confirm anything right now. Click to show
|
@Xeunyx-Cypher
This should have nothing to do with this, though. If anything, restricting the protocol to TCP only will result in you connecting to less peers (since some may communicate exclusively with If you cannot reproduce, this might have just been a spurious issue, or something else changed in time or your system's/network's configuration between the time when you had the torrent in uTorrent and now. The settings look fine. If the problem persists and is reproducible, please also post:
and
|
Yeah, seems you are right. Enabled the "utp protocol" and didn't face the issue. Can it happen because I was downloading a file in qBit with high speed at the same time? But then again the question arise, Why uTorrent was able to Upload at that SAME time without affecting the download speed in qBit.
Can't disagree as I can't sort the problem out.
Click to show
|
This is the easy way out answer since the whole world and their in-laws can't get any speed in qB with uTP protocol enabled. So if you can't reproduce this, enlight the rest of the world with your settings. To be clear, I can't get uTP to work in qB either. |
It's the logical answer. It makes no sense for connectivity to increase after disabling one of the protocols that peers in the swarm can speak (in fact, some of them don't use TCP at all, so you can't connect to them unless you have uTP enabled).
werks on my machine. You need to provide evidence/data to substantiate such claims. Without data suggesting otherwise, it is logical to assume that uTP works fine for 99% of people, since there is only the occasional complaint. And, in my experience, every time someone complains about uTP, it turns out it was correlation, not causation, relating to a connectivity/performance problem somewhere else[1]. This is true for this issue tracker, as well as multiple other online communities, such as libtorrent's issue tracker, and several prominent private trackers - but feel free to point me to where "the whole world and their in-laws can't get any speed in qB with uTP protocol enabled." qBittorrent relies on libtorrent 100% for uTP. If it had a serious problem with uTP, everyone would know about it already, believe me, since libtorrent is used in multiple torrent clients and even other applications that need to work with the BitTorrent network.
In most of my deployments I run qBittorrent with default settings (this means uTP on) except: queuing disabled, asynchronous I/O threads set to 4 times the number of logical CPU cores available, disk cache set to auto or something like 256 MiB. Furthermore, when I'm torrenting on my laptop, I tend to only enable uTP, for 2 reasons:
Other than that, my home network is just a run-of-the-mill dual-stack NAT with static IPs (or at least, rotation periodicity measured in years), (good) UPnP support (so that I don't have problems with port forwarding), and generally good networking hardware that does its job, doesn't bottleneck me, and stays out of my way. On some machines I'll also use Mullvad VPN.
Please open a new issue with as much detail as possible, as this is a separate problem - OP was able to get uTP working (#13073 (comment)), so the problem is something else. First, try to bump up the disk cache and asynchronous I/O threads parameters to the values suggested above. Other than that, without more data, I would suspect either bad router (e.g. provided by ISP) that can't handle many uTP connections (or otherwise messes with them), "antivirus"-related bullshit (if you're on Windows), or some kind of network misconfiguration. For the issue to be useful, you need to prove beyond a reasonable doubt that the problem is not your end - [1] Of course, once again, this turned out to be the case (#13073 (comment)):
|
This is a discussion that runs for years now on libtorrents git which clearly states that uTP in libtorrent (and thus qB) is wonky at best. |
@Xeunyx-Cypher
Depends on how much "high speed" you're talking about, the specs on your machine (e.g. HDD vs SSD), and how well you controlled variables when testing with both clients. Statements like:
are not very useful for comparing performance between clients, unless you have a proper testing methodology. For example, same torrents, similar times of day, nothing else running in the background, same storage medium used (e.g. always SSD or always HDD) etc. And even then, you're not accounting for swarm variability and other important stuff. That being said, qBittorrent should not be slower than uTorrrent, all else being equal. If you're seeing performance problems, you might have some settings misconfigured - typically the number of "asynchronous I/O threads" and the "disk cache size". Try setting "asynchronous I/O threads" to 4 times the number of logical CPU cores (basically, the number of hardware threads) on your machine (so 4c/8t and 8c/8t gives 4*8=32, while 4c/4t gives 4*4=16), and "disk cache" to This is a bit of a pet peeve of mine - unfortunately, qBittorrent ships with asynchronous I/O threads set to a value that bottlenecks most typical setups nowadays.There are already some discussions open about that here.
All of these 3 torrents are (at the time of writing) still very well-seeded. You won't see much upload just because while there is still some demand, the current supply more than covers it. I was able to download all three, while uploading just fine the entire time, and see for a while after until I stopped them (on a machine with an SSD). |
I skimmed through it, and it seems that discussion was never about uTP not working at all, but about reduced speed under specific circumstances. It seems to be a Windows-only problem (arvidn/libtorrent#3542 (comment)), and so far was only reproduced in quite a specific scenario - specifically, over loopback, with uTorrent uploading (arvidn/libtorrent#3542 (comment)). It could very well be an issue on uTorrent's side actually. Not so easy to confirm, as uTorrent is not open source. The torrents provided by OP were well seeded, by a variety of clients other than uTorrent, so that issue should not have much impact at all in this one. |
I have the same situation as you, the description is exactly the same. In the same system environment, qb upload speed is 0kb/s, ut |
arvidn pointed out he duplicated the bug via windows, uTorrent -> qBT using local loopback, but did not state whether he did further tests. However the problem should not prevent downloading or uploading, only slowing it. |
@arvidn ping |
The issue is not limited to utorrent peers. I’ve seen this issue in between qbit to qbit and deluge to qbit over uTP. The speeds are horrible over uTP. Switching to TCP only provides a massive improvement in speed. This issue is 100% reproducible. |
@An0n666 if you can reproduce it with uTP logging enabled, those logs should really help in understanding what's going on. |
@arvidn Both ends of a uTP stream may not need to be on a windows OS. Also, where is uTP logging on qBitTorrent? |
But does at least one end need to be windows in order to reproduce it? |
I don't know and I don't have a non-windows OS + qBitTorrent set up to test for that. |
Downloading in a Windows machine(using qBt) from a ubuntu VM(seeding using qBt) on the same PC gives stable speeds(50 MiB/s) over Downloading over Now if you reverse that and seed from a windows machine to a ubuntu VM: The worst of all is on |
I would like to disagree. I think qBt community is less into racing. If you go to deluge community almost everyone recommends you to disable uTP due to its poor performance on libtorrent. Also there seem to be a prejudice created by a group of people that this issue only affects utorrent. But that’s not the case. This is an issue exclusive to libtorrent. I’ve tried multiple other mainline bittorrent clients and all of them provide same or better performance over uTP with utorrent. |
Interesting. I was not aware this was such a widespread practice. Though I wonder how often these providers validate their settings. It might be the case that a lot of them aren't even affected by this (or at least, not anymore), but still do it because "if it ain't broke, don't fix it".
Because disabling is the easy fix. Lack of detailed logging in clients like qBittorrent is definitely an obstacle, but not really an excuse - if it is known with such certainty that this is a libtorrent issue, one can just as easily spin up Providing detailed and reliable steps to reproduce is the ultimate goal, but it is not strictly necessary for a performance issue claim to not be "thrown in the garbage" right away. A detailed account of experimentation with some images/results done in some semblance of a controlled environment is enough to start. For example, your post right here #13073 (comment) meets this requirement, and would have definitely caught the attention of everyone if it were the first post about this issue. The problem is that, as you know, the vast majority of people don't do this, often even after being told how/what to do.
I wouldn't call it a prejudice - uTorrent's involvement in this issue has been mentioned since very early on in arvidn/libtorrent#3542. So it is understandable that until more information surfaced about this happening with other clients (and now, even with the very same client on both ends), some would assume, or at least suspect, that uTorrent specifically might be at fault. I wonder how and why exactly this issue affects so many people but not others. I still can't reproduce it myself. Since you are able to reproduce the issue, I would suggest trying out the following scenarios as well (this is also valid for anyone else who can reproduce the issue):
It's also worth noting that this particular report was confirmed to not have anything to do with libtorrent's uTP performance (#13073 (comment)). I should have closed this before. I would encourage continuing the discussion about libtorrent's uTP performance in arvidn/libtorrent#3542. |
Please provide the following information
qBittorrent version and Operating System
v4.2.5 | Win10 x64 v1903
What is the problem
Torrent status "Seeding" but UP Speed stays "0" most of the time.
What is the expected behavior
Generally seeding with the UP speed.
Extra info(if any)
Same torrent file which I can seed with uTorrent 3.5.5 without any issue can't seed with Qbittorrent. The status shows "seeding" but most of the time the UP speed stays "0" or idle even though I connect/disconnect with the peers all the time. Ofc the torrent has leechers and it normally seeding in uTorrent as expected. Checked my Bitdefender Firewall and Qbittorrent is allowed for all connections.
Any kind of help would be much appreciated
The text was updated successfully, but these errors were encountered: