qBittorrent
qBittorrent copied to clipboard
qBittorrent 4.3.9 can not download to an external HDD
Please provide the following information
qBittorrent version and Operating System
qBittorrent v4.2.5 Arch Linux 5.6.12
If on linux, libtorrent-rasterbar and Qt version
Qt 5.14.2 Libtorrent 1.2.6.0 boost 1.72.0 OpenSSL 1.1.17 zlib 1.2.11
What is the problem
When qBittorent download location is on an external HDD, at first the download speed is high, say 10 MB/s. After ~1 min it gradually drops to ~200 B/s, then to 1 B/s and then stalls. Every download stalls.
What is the expected behavior
Download to an external HDD.
Steps to reproduce
Download ~30 GB torrent to an external HDD.
Extra info(if any)
The Transmission client does not experience such a problem, so that's not on the HDD part.
[AddNewTorrentDialog]
DialogSize=@Size(1225 621)
RememberLastSavePath=false
[Application]
FileLogger\Age=1
FileLogger\AgeType=1
FileLogger\Backup=true
FileLogger\DeleteOld=true
FileLogger\Enabled=true
FileLogger\MaxSizeBytes=66560
[AutoRun]
enabled=false
program=
[BitTorrent]
Session\AsyncIOThreadsCount=16
Session\BTProtocol=TCP
Session\DisableAutoTMMByDefault=false
Session\SubcategoriesEnabled=true
[GUI]
DownloadTrackerFavicon=false
Log\Enabled=true
Log\Types=-1
Notifications\Enabled=true
Notifications\TorrentAdded=false
[LegalNotice]
Accepted=true
[Network]
Cookies=@Invalid()
[Preferences]
Advanced\DisableRecursiveDownload=false
Advanced\RecheckOnCompletion=false
Advanced\TrayIconStyle=0
Advanced\confirmRemoveAllTags=true
Advanced\confirmTorrentDeletion=true
Advanced\confirmTorrentRecheck=true
Advanced\trackerPort=9000
Advanced\useSystemIconTheme=true
Bittorrent\AddTrackers=true
Bittorrent\MaxConnecs=-1
Bittorrent\MaxConnecsPerTorrent=-1
Connection\PortRangeMin=12518
Connection\ResolvePeerCountries=true
Connection\ResolvePeerHostNames=false
Downloads\DblClOnTorDl=1
Downloads\DblClOnTorFn=1
Downloads\NewAdditionDialog=true
Downloads\NewAdditionDialogFront=true
Downloads\PreAllocation=true
Downloads\SavePath=/run/media/user/hdd
Downloads\ScanDirsV2=@Variant(\0\0\0\x1c\0\0\0\0)
General\AlternatingRowColors=true
General\CloseToTray=true
General\CloseToTrayNotified=true
General\CustomUIThemePath=
General\DeleteTorrentsFilesAsDefault=true
General\ExitConfirm=true
General\HideZeroComboValues=0
General\HideZeroValues=true
General\Locale=en
General\MinimizeToTray=false
General\NoSplashScreen=true
General\PreventFromSuspendWhenDownloading=false
General\PreventFromSuspendWhenSeeding=false
General\StartMinimized=false
General\SystrayEnabled=true
General\UseCustomUITheme=false
General\UseRandomPort=true
MailNotification\email=
MailNotification\enabled=false
MailNotification\password=
MailNotification\req_auth=false
MailNotification\req_ssl=false
MailNotification\[email protected]
MailNotification\smtp_server=smtp.changeme.com
MailNotification\username=
Queueing\QueueingEnabled=false
Scheduler\days=0
Scheduler\end_time=@Variant(\0\0\0\xf\x4J\xa2\0)
Scheduler\start_time=@Variant(\0\0\0\xf\x1\xb7t\0)
State\hSplitterSizes=163, 804
State\size=@Size(993 866)
WebUI\Enabled=false
[RSS]
AutoDownloader\DownloadRepacks=true
AutoDownloader\SmartEpisodeFilter=s(\\d+)e(\\d+), (\\d+)x(\\d+), "(\\d{4}[.\\-]\\d{1,2}[.\\-]\\d{1,2})", "(\\d{1,2}[.\\-]\\d{1,2}[.\\-]\\d{4})"
[ShutdownConfirmDlg]
DontConfirmAutoExit=false
[SpeedWidget]
Enabled=true
graph_enable_0=true
graph_enable_1=true
graph_enable_2=false
graph_enable_3=false
graph_enable_4=false
graph_enable_5=false
graph_enable_6=false
graph_enable_7=false
graph_enable_8=false
graph_enable_9=false
period=1
[TransferListFilters]
selectedFilterIndex=0
then to 1 B/s and then stalls.
Does it ever pick back up?
Despite the stalling, do you see drive activity, or it just stops?
Does it ever pick back up?
No, it does not even after ~8 hours. After kill -9 qbittorrent and restarting, it downloads for a minute then stalls again.
Despite the stalling, do you see drive activity, or it just stops?
It seems there is some activity both with and without the space preallocation setting.
Not really sure what the problem could be tbh, and don't really have the means to reproduce this right now, unfortunately. Maybe someone else has an idea.
maybe disk issue? try "dmesg" and "fdisk -l"
EDIT (FranciscoPombal): no need to quote the entire OP. Tag the user if it is not clear who you are responding to. Use quotes when you want to emphasize a certain part of the post you are addressing.
@FranciscoPombal Maybe something with system/non-system writing caches and their size and timeout?
It's not a disk issue: Transmission-qt works without any problems, so does uTorrent 1.8 on Windows.
From a relevant thread on Reddit
I've been using Qbittorrent and the issue I have is
When I save a torrent to the external drive, it begins downloading at expected speeds (5-10 megabytes a second) but then within a minute or so the speeds start to go very slow, like 100KB/s or less and keeps slowing, then the torrent changes to "stalled" state.I've switched to BitTorrent and the issue seems to have been resolved.
Also https://github.com/qbittorrent/qBittorrent/issues/8186
@homocomputeris
Did you read https://github.com/qbittorrent/qBittorrent/issues/8186#issuecomment-571273424 and https://github.com/qbittorrent/qBittorrent/issues/8186#issuecomment-571289691?
You could try the suggested settings in the first linked comment. I would also test whether or not preallocation is really needed. Also you should not need admin privileges. If you actually need them, that's probably a bug.
enabling coalesce reads & writes may be of help too.
@FranciscoPombal I have the settings from the 1st comment, they have not helped since 4.2.2 at least when I noticed the problem the 1st time. I have tried changing the cache size, enabling/disabling OS cache, coalesce, preallocation and other read-write related options.
The HDD is NTFS formatted.
@homocomputeris maybe try ext4 instead of ntfs
I am seeing the same issue on a ext4 external drive. I am on the last master commit. (35a32656573613bb98331696163166a2b27a4574)
same problem running wBitttorrent 4.2.5 from MacOS Mojave writing on external HFS+ (Journaled). Forcing Resume will have the torrent running again for a few seconds. Some files manage to finish the download this way, some are going back to 0% and are stuck no matter what.
I cleared qbittorrent cookies (Tools / Cookies Manager) and after reboot, the problem with download is away. My external HDD is NTFS formatted.
definitely didn't work for me @brand1970 added a bunch of torrents recently and it stopped working all together. Had to change port to have torrents starting again. I suspect – at least for my case – that it might have something to do with downloading on multiple download paths / multiple external HDD
I have a feeling that it breaks when the download speed is higher than the HDD writing speed. When downloads are slow, I believe I don't see this stalling.
QBT can download a 3.5 GB torrent with no issues, but 39 GB torrent stalls. Maybe, something with block/sector/etc size of HDD?
@homocomputeris I'm not a linux user but...........here are some things to look into. @FranciscoPombal can you look/advise on my suggestiond too, please.
Have you big_writes enabled? (feature was deprecated in 2016....but still in use for some distro's)
Is NTFS disk compression enabled?
is drive mounted with sync or async?
Has drive been de-fragmented recently?
@CorentinB what OS are you running under?
@xavier2k6
Have you
big_writesenabled? (feature was deprecated in 2016....but still in use for some distro's)
Shouldn't matter, this is only important for performance. The option is now deprecated because it is always on by default, but no stable release of ntfs-3g has been made so far that includes that change. Still, some distros may already include the patch.
Defragmentation should help with performance, but not much else.
Not really sure if the other things matter or not...
Have you big_writes enabled? (feature was deprecated in 2016....but still in use for some distro's)
I have no idea. I use the default Arch settings.
Is NTFS disk compression enabled?
Is it a thing in Linux?
is drive mounted with sync or async?
I use the default Gnome automount options.
Has drive been de-fragmented recently?
Yes, it has.
Still exists in 4.3.1
facing the same on the latest macOS Catalina with the latest app version, external HDD is USB 3.0 on exFAT connected directly to the mac. I saw the following errors:

Transmission has no issues downloading to the same HDD.
Still an issue in 4.3.7
Still an issue in 4.3.9
what about now?? my external HDD work fine
This is an issue on v4.4.5 on Windows. Also, once the torrent gets stuck at 0b/s or "stalled", quitting qbittorrent results in the tray icon remaining. qbittorrent must then be force closed from task manager.
Having similar issue with Linux 4.5.0. I seem to have less of a problem if I keep the number of active torrent downloads to 4 or less (and perhaps more stable if I keep it to 2 active torrents). The problem doesn't seem to be the download speed.
My guess is the drive is overwhelmed by too much activity, and then decides to go manic.
having the same problem on intel i7 2019 macbook, latest OS X. External SSD exfat format, connected with USB 3.0, tested and has usb 3.0 speeds. Torrent download is totally halted, no progress at all. Starts fast with 30mb/s speeds then goes to a total halt and never recovers, even after hours progress is still 0%.
The problem does not reproduce if I download to internal ssd. This has a major impact for me as I've got an 8tb external drive that I want to use as my daily drive.
Can anyone reproduce on 4.6.6 ?
This ticket has been closed.
Closure Reason: being "out-of-date", and thus either most likely resolved in recent versions or no longer applicable.
-
If you experience the reported problem or similar in the latest version, please open a new issue report with the requested information in the issue template.
-
Due to the changes made to the qBittorrent code and its dependencies over time, the exact cause of your problem could be totally different than the original one, despite the visible symptoms of the bug being similar.
-
Thus, providing relevant updated information is crucial to find and fix the root cause of a recurrent problem or regression.
-
A new issue report with relevant updated data gathered from the latest version is preferable to necroing an old report with a comment like "still happens in version x.y.z", even if you think the bug is the same, or suspect of a regression.
-
Thank you for your contribution(s).