mirror of
https://github.com/qbittorrent/qBittorrent.git
synced 2026-03-02 22:57:32 -05:00
qBittorrent crashes to desktop CTD when saving to a ksmbd network location via OpenWrt/performance issues with f2fs filesystem. #17090
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#17090
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 @sppmasterspp on GitHub (Aug 19, 2025).
qBittorrent & operating system versions
qBittorrent version: v5.1.2 (64-bit)
Qt: 6.9.1
Libtorrent: 2.0.11.0
Boost: 1.86.0
OpenSSL: 3.5.2
zlib: 1.3.1
OS version: Windows 11 Pro Version 24H2, OS Build 26100.4946
RAM - 32.0 GB.
What is the problem?
I have really obnoxious constant crashes to desktop without any visible messages.
Before qbitorrent crashes completely the down/up speeds decrease to almost zero and then qbittorent simply exits without any message.
I have several memory dumps.
Using latest 5.1.2 qt6 lt20 build. I've tried 5.2.0 nightly build too, same crash to desktop.
The worst part is that the torrent progress is lost and after the crash the torrents start from the beginning.
Steps to reproduce
Simply leave the program running in fore/background and the up/down speeds fade out to almost zero and then the program crashes to desktop. In my case that happens in just 5-15 minutes from the start.
Addition - Later I found that it is related to writing/reading the data to a NAS device in my case connected to an OpenWrt router and shared with ksmbd over the LAN.
Additional context
Look below in the comments for more exact info about the actual issue.
https://github.com/qbittorrent/qBittorrent/issues/23126#issuecomment-3236958625
@xavier2k6
Log(s) & preferences file(s)
CrashDumps.zip
Those crash dumps may be a mix of v5.1.2 and 5.2.0 alpha builds.
Important info - currently there is a workaround but in my case write speed is still very low.
@stalkerok commented on GitHub (Aug 19, 2025):
Is this the release version?
@qBittUser commented on GitHub (Aug 19, 2025):
Google search shows that's stable release channel.
https://support.microsoft.com/en-us/topic/august-12-2025-kb5063878-os-build-26100-4946-e4b87262-75c8-4fef-9df7-4a18099ee294
@qBittUser commented on GitHub (Aug 19, 2025):
@sppmasterspp
Does crash happen with libtorrent v1.2 builds?
@qBittUser commented on GitHub (Aug 19, 2025):
Did you modify qBittorrent or is it a typo?
@xavier2k6 commented on GitHub (Aug 19, 2025):
@sppmasterspp
C:\Program Files\qBittorrentsfc /scannowin an elevated command prompt@sppmasterspp commented on GitHub (Aug 19, 2025):
Thanks for looking into this.
I haven't modified it in any way but the info was copied from 5.2.0 alpha build that I currently test because the same crash to desktop and behaviour happened on latest v5.1.2.
I haven't tried with libtorrent v1.2 builds.
Devices, where I download to, have plenty (hundreds of Gigabytes) of free space available.
@xavier2k6 commented on GitHub (Aug 19, 2025):
Did you do this?
@sppmasterspp commented on GitHub (Aug 19, 2025):
Yes, check it.
@xavier2k6 commented on GitHub (Aug 19, 2025):
Any corrupt OS files?
@sppmasterspp commented on GitHub (Aug 19, 2025):
No, only those three files.
And my system is really stable with lots of other Virtual Machines, Software used and Games run frequently, no other crashes were observed.
@sppmasterspp commented on GitHub (Aug 28, 2025):
Super flaky behaviour. Sometimes crashes every 2 or 3 minutes. Cannot even check 16 GB torrent after the crash. Looks like a crash loop.
When only seeding it doesn't crash or at least works for several hours.
I've tried to use only IPv4 but it crashes in this case too.
Here are some new dumps.
CrashDumps 2.zip
From event log
@xavier2k6
@xavier2k6 commented on GitHub (Aug 29, 2025):
@sppmasterspp Please run memtest or equivalent to check your memory, I will provide a build later with updated dependencies & I may need you to attach a debugger with pre-defined rules.
@sppmasterspp commented on GitHub (Aug 29, 2025):
@xavier2k6 I
I've run Memtest86+ (complete pass) and additionally Prime95 (with Large FFTs) for several hours.
No faults detected and this PC is heavily used for code compilation, games, video encoding and other really heavy tasks.
My system is really stable with no BSOD or other faults (I run several VMs, including Linux that I use to compile a code. etc.
@xavier2k6 commented on GitHub (Aug 29, 2025):
BTW, Any VPN in use?
@sppmasterspp commented on GitHub (Aug 29, 2025):
Not currently on this machine.
I do use VPNs with split tunneling on my OpenWrt router but I repeat not currently with this PC.
I used VPN to tunnel torrent traffic for a few months without any issue though.
I used Policy-based QoS under Windows to mark the qbittorrent traffic under Windows and the router had a policy rule set and recognized the marking and redirected it through the VPN.
But currently I don't use that.
@sppmasterspp commented on GitHub (Aug 29, 2025):
@xavier2k6
Let's narrow the issue down. It doesn't crash when I save data to any local HDD/SSD device.
I've just made several tests and I've found that qbittorrent crashes when it saves the data to one network attached SSD drive.
Maybe you remember this issue - https://github.com/qbittorrent/qBittorrent/issues/21669. There you can find my setup described.
I have two SSD (2 TB) drives attached to my network. They are connected to an OpenWrt router and an OpenWrt managed switch.
Interestingly when I download to the SSD attached to the router there is no crash.
The only downside is that the write speed is unexpectedly low (max around 12 MBps and the same torrent is written with over 50 MBps when saved to a local drive).
If I use Windows File Explorer (or Total Commander or other Torrent program) to copy data, they write at over 100 MBps and that is expected with the 1 Gbps cable connection. With qbittorrent max speed is ~12 MBps writing to network device when it doesn't crash.
Now the actual issue - qBittorrent crashes to desktop (CTD) when saving to a network location. Slow write speed to network device.
When I download to the second SSD drive (attached to device running OpenWrt) the crash occurs as described.
I've just tried to copy over 200 GB of data from a local drive using both File Explorer and Total Commander and no issues at all.
@qBittUser commented on GitHub (Aug 29, 2025):
Open qBit advanced settings and change Disk IO type to be Simple pread/pwrite, apply and restart.
It was added to v5.0.1 by this pull:
It might help with your external disks and solve other issues.
Otherwise you should also try using default libtorrent v1.2 build and latest default settings to verify that if your issues are related to specific settings or libtorrent.
Unfortunately quite often official release installers do include extra libtorrent fixes than what's in the GitHub nightly builds, so you can also try v5.1.2 again with the simple Disk IO type.
@sppmasterspp commented on GitHub (Aug 29, 2025):
I've done it but doesn't help with 5.2.0.
This time it threw torrent I/O error and Unexpected network error but didn't crash.
In the OpenWrt log I could see this error - kern.err kernel: [123948.465414] ksmbd: Failed to send message: -11
So now installing 5.1.2 to try with it. Just waiting for the checking to finish.
I good thing will be if there is an indication of the read speed when checking a torrent because that may indicate/reveal other issues if the reading speed is too low. And currently I think it reads the torrent at really low speed.
@qBittUser commented on GitHub (Aug 29, 2025):
Then it did help with your main issue if no more crashes and helped to find there's now a new issue with this workaround.
This reminded me you had made a issue report before:
So maybe your new issues are again related to changes to OpenWrt and not fully fault of any libtorrent or qBittorrent version.
Once your certain what's necessary to get things working or to reproduce your issues, then you should update your opening post. Otherwise leaving as it is would confuse new curious users and take more time to diagnose or to even confirm that anyone can reproduce your issues.
@sppmasterspp commented on GitHub (Aug 29, 2025):
Yep that's exact.
Just managed to test with 5.1.2 and Simple pread/pwrite. It doesn't error nor crash but the write speed is slow - max ~12MBps where it should be above 100MBps for 1G LAN interface. I suspect that the reading speed is slow too, and that's important in case torrent checking is necessary.
Once again, other file management programs don't have issues writing/reading at full 1G speeds to this NAS device.
Of course, but I will keep the initial description because someone else with similar setup to mine (although it may be rare) may encounter the same issue initially not knowing it's NAS related only.
I've added some more clarifying info to the first post.
@xavier2k6 commented on GitHub (Aug 29, 2025):
Can you test below build?
https://github.com/xavier2k6/qBittorrent/actions/runs/17335332437/artifacts/3887223829
It's created from latest merged qBittorrent
mastercommit, latest merged libtorrrentRC_2_0commit, Qt 6.9.2, Boost 1.89.0, OpenSSL 3.5.2, zlib 1.3.1@sppmasterspp commented on GitHub (Aug 29, 2025):
Download to the discussed SSD NAS location.
With default Disk I/O type started optimistic with two torrents achieved ~18 MBps but after only 3-4 minutes speed dropped to zero and qbittorrent crashed.
With Simple pread/pwrite it's still downloading for 25 minutes at really slow speed ~3-5 MBps but still no error thrown. It's running as fast as a helix but doesn't crash.
Download to a local HDD.
Before that I ran both torrents for a few minutes to a local drive and they downloaded at 30-40 MBps.
@xavier2k6 commented on GitHub (Aug 30, 2025):
Ah.......I remember now - your unique case.......Any newer kernel/firmware for your device?
@sppmasterspp commented on GitHub (Aug 30, 2025):
I'm on latest kernel 6.12.43, because I compile OpenWrt build myself and I do it frequently and update.
I feel a real sympathy to use qbittorrent but because of this error I've had to return to a previously used torrent program that I've left in the past just because qbittorent has given me such an excellent results and speeds for the last three years.
And boom after more than three years that other program has pleasantly surprised me with its flawless and speedy work and low system resources used. Obviously a good job done.
Another curious fact is the number of the active connections.
When I start qbittorent I have this in my router status no matter if it downloads or seeds only.
When I run the other torrent program I have this although it's downloading at full speed (above 40 MBps).
@sppmasterspp commented on GitHub (Sep 29, 2025):
@xavier2k6
Some fresh info. With current kernel 6.12.48 no more crashes but still I see slow write/read speed (max 12-13 MiB/s) to/from ksmbd network location using f2fs file system. With other programs I can get over 110 MiB/s.
I'll try with ext4 and report back.
@xavier2k6 commented on GitHub (Sep 30, 2025):
@sppmasterspp Have you done any testing with Kernel 6.13.x+?
@sppmasterspp commented on GitHub (Sep 30, 2025):
Nope, I use OpenWrt and the latest kernel for my router is 6.12.49 currently, but there are many upstream backports to 6.12.x.
If you know about any upstream commit that resolves this I think it can be backported to 6.12 and 6.6.
Ping @namjaejeon
@namjaejeon commented on GitHub (Sep 30, 2025):
@sppmasterspp Can you try to reproduce it after reverting the following two patches ?
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/smb/server?h=v6.12.49&id=d5ab785183aed260739e802bbb0003857f5ee75c
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/fs/smb/server?h=v6.12.49&id=7e5d91d3e6c62a9755b36f29c35288f06c3cd86b
@sppmasterspp commented on GitHub (Sep 30, 2025):
If this is the same as the revert PR from @pesa1234 - https://github.com/openwrt/openwrt/pull/20192 then yes I've tried it.
I've compiled a build with it applied 3 days ago and no change at least regarding the low write/read speed. But this low performance is only when I use qbittorrent.
But actually this low speed is at least several months old but I just had time to report it a month ago.
@Neustradamus commented on GitHub (Sep 30, 2025):
To follow this ticket :)
@qBittUser commented on GitHub (Sep 30, 2025):
@Neustradamus
Then you should just click the
subscribebutton to get notifications instead of anything else.@namjaejeon commented on GitHub (Sep 30, 2025):
@sppmasterspp
Honestly, I don't think there have been any patches to ksmbd that would have downgrade a performance of ksmbd, and if this issue has been around for several months, there are too many patches to review.
Can you test it with samba instead of ksmbd? I just want to know if it is qbittorrent issue or not.
@sppmasterspp commented on GitHub (Sep 30, 2025):
Yep I can, but will have to find some spare time first so maybe a few days or so.
@xavier2k6 commented on GitHub (Dec 26, 2025):
@sppmasterspp Can you provide an update here please?
@sppmasterspp commented on GitHub (Dec 26, 2025):
Yes, give me some more days, I'll test it with Samba after the New Year and report. My last test was just 2 days ago with latest qBittorrent and latest Ksmbd and still I see speed cap.