We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
The issue was also reproducible on version 3.1.12.
3.1.12
qBittorrent: 3.2.5 Qt: 5.4.2 libtorrent: 1.0.7.0 boost: 1.56.0 OS version: Gentoo x86_64
Reproducible: Always
Steps to reproduce: There are torrents located on 2 HDDs, /h1 and /h2.
/h1
/h2
Seeding speed goes back to ~300KB/s once files are checked.
It seems that this issue was also mentioned in #2602:
In addition, it greatly slows down my download speed on other files.
since the other issue is about checking speed itself, and this remark seems to have been ~forgotten, I've opened this issue.
The text was updated successfully, but these errors were encountered:
libtorrent is single threaded and as a forced recheck is a high priority task, ALL other processing ceases until the check is complete.
This also applies to moving payloads between filing systems or drive letters on Windows.
Sorry, something went wrong.
Closing as far too old, there have been many improvements to libtorrent since then, this is most likely fixed.
No branches or pull requests
The issue was also reproducible on version
3.1.12
.Reproducible: Always
Steps to reproduce:
There are torrents located on 2 HDDs,
/h1
and/h2
./h1
are being seeded with speed ~300 KB/s./h2
are being checked, global seeding speed of all torrents, also the ones located on/h1
goes down to 1-2 KB/s.Seeding speed goes back to ~300KB/s once files are checked.
It seems that this issue was also mentioned in #2602:
since the other issue is about checking speed itself, and this remark seems to have been ~forgotten, I've opened this issue.
The text was updated successfully, but these errors were encountered: