mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
3.2.1: disk overload #2781
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#2781
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 @vulc on GitHub (Jul 13, 2015).
thats reason why i migrated from utorrent.

Let's go downgrade to 3.2.0.
@chrishirst commented on GitHub (Jul 13, 2015):
A translation would be useful.
AND the usual question of WHAT operating system.
@vulc commented on GitHub (Jul 13, 2015):
Windows 8.1 x64. And this problem on every Windows editions and versions.
I don't know what to exactly need to translate. Disk load 100%.
For example: https://goo.gl/xIvpJJ
It seems - world do not know the nature of this phenomenon and can't solve it.
Just waiting multiple confirmation about problem from other qbit users.
@chrishirst commented on GitHub (Jul 13, 2015):
Any of it. All of it. Whatever 'it' is. It could be tomorrows weather forecast for lake Baikal. for all the sense it makes to me.
And I can tell you exactly what causes the disk overload in uTorrent, a badly set up cache and rate limits.
@sledgehammer999 commented on GitHub (Jul 13, 2015):
what is the values you have in "disk write cache size" and "disk cache expiry interval" in the advanced settings of qbt?
What is your download speed?
Is your disk a local disk or a networked one?
Does v3.2.0 have the same problem?
@vulc commented on GitHub (Jul 13, 2015):
2.5 MBytes download speed.

Local disk.
v.3.2.0 don't have this problem!
thank for supporting.
@sledgehammer999 commented on GitHub (Jul 15, 2015):
I have posted to the libtorrent mailing list. Waiting the author's answer.
@vulc commented on GitHub (Jul 19, 2015):
If author wishes, I would like to give access to my PC (via TeamViewer. ID 724 624 455)
@sledgehammer999 commented on GitHub (Jul 19, 2015):
Have you enabled pre-allocation?
@vulc commented on GitHub (Jul 19, 2015):
I didn't change any settings from 3.2.0. Just installed 3.2.1 over 3.2.0.

Pre-allocate still disabled.
@sledgehammer999 commented on GitHub (Jul 25, 2015):
Can you do these steps:
qbittorrent.exeentry in the "Processes" tab of Task ManagerIf the file is small enough email it to me. Otherwise try to upload it somewhere and link here.
email: sledgehammer999 (at) qbittorrent (dot) org
@uLuGaBi commented on GitHub (Sep 3, 2015):
Hello,
I can encounter same problem. Before never had problem: Downloading full speed like 30 mb/s without any issue and uploading was great with sometimes some disk overloads. Those diidn't happened when i'm seeding directly from my NAS using transmission.
Then switched to 3.2.3 64 bits version and now i can't even download. It s always get stucks with disk overload, even directly at start sometimes. Upload become the same, tried reduce speed even to 1 mb/S but still bugging. Tried used seed from 6tb HD or from my NAS (5*3tb RAID 5 connected by gigabit ethernet) but still same problem.
Also tried change cache size or cache expiry time but buffer size don't change.
When i look at statistics read/write overloads are at 0%, no many pending I/O then suddenly I/O come to 1500. This happen every 3/7 minutes and freeze download or upload for one minute which finally kill download speed or upload. If i look at statistics it's finally made an average of less than 1.5 mb/S per second for upload.
Considering line is 25 mb/S capable and it's using gigabit ethernet with 5 HD in raid i find it strange.
@uLuGaBi commented on GitHub (Sep 3, 2015):
Looking at ressources monitor it could be linked to fastresume files:
When it happens there are many tasks writing to BT_Backup fast resume files.
Only disk which seems having lot of I/O is C: This disk is a M2 SSD disk and i'm running thousands torrents but only 2 active downloads and 1 active upload
I also sent you the dmp file
@sledgehammer999 commented on GitHub (Sep 4, 2015):
@uLuGaBi if you can test v3.3.0beta builds. The v3.2.x series have almost come to an end. v3.3.x has major core refactoring.
v3.3.0beta: http://www.fosshub.com/qBittorrent.html
@uLuGaBi commented on GitHub (Sep 4, 2015):
Bit busy for this week so before testing:
Is it really unstable ?
I used the QT5version, not gonna create problem since i see it's QT 4.8.7?
Had many GUI problems with 32 bits version when passing 3000 torrents (slowness, no more able to sort torrents, not able to perform actions like moving or resume files), do you think it will continue on this version rather than the 64 bits one?
@sledgehammer999 commented on GitHub (Sep 4, 2015):
3.3.0 is nearing release. It is very stable. Actually it is called beta/unstable just because we keep adding features and tweak things.
No problem between qt5 and qt4. Your columns and window sizes maybe different but once you go back to qt5 they should return(the settings are saved in different locations for qt5).
The GUI issues should be non-existent with 3.3.0.
@uLuGaBi commented on GitHub (Sep 5, 2015):
But no 64 bits version?
@chrishirst commented on GitHub (Sep 5, 2015):
Watch this space >>>
@uLuGaBi commented on GitHub (Sep 7, 2015):
I meant 64bits version of 3.3.0. So tell me if i'm wrong but i don't see it in 64 bits
@sledgehammer999 commented on GitHub (Jan 25, 2016):
Does v3.3.3 show the same problem?