Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Please provide the following information
qBittorrent version and Operating System
Any version on any OS.
If on linux, libtorrent-rasterbar and Qt version
What is the problem
qBittorrent currently ships with the
What is the expected behavior
qBittorrent should either ship with this set to at least
Steps to reproduce
Download moderately large torrent that takes some time to recheck.
Extra info(if any)
I edited the wiki page with these findings - https://github.com/qbittorrent/qBittorrent/wiki/Explanation-of-Options-in-qBittorrent/957bb3f50d0cff41f33b58d90b581409a648b089
Setting values greater than n*4 for this setting will most likely not help and at worst reduce performance as well due to extra thread overhead.
Increasing the value of this setting might not help (at least very much) if the storage medium is a severe bottleneck for the system already, but in that case it should not hurt much if at all either.
Nice, this pretty much confirms my initial analysis/prediction.
We just went through disabling qBittorrent from being able to perform multiple force-rechecks at the same time. In the majority of machine configurations, you do not want to have two torrents being checked / rechecked, otherwise it causes undue disk thrashing and random seeks. Almost all drives perform best with sequential seeks, reading one-file-at-a-time.
Sure, but this discussion is not about force-rechecks, it's about the SHA-1 calculations of pieces that are downloading.