sgghostrider
commented
8 months ago This seems as a common and really under-reported problem that was driving me crazy since the release of 4.6.0 and that i hoped after several updates it would be fixed, after every patch i kept seeing the same problem every time... with 4000+ torrents(14TiB+) nowadays it takes me HOURS to finish the check of the resume data of all my torrents...(local network NAS with 2.5Gb/s NIC and 200MiB/s R/W speed).
I have a strong suspicion that qBittorrent v4.6.X+ have some kind of problem that prevents it from reading parts of the ".fastresume" data and it regenerates it on "every-damn-startup", installing ANY previous version fixes the problem INSTANTLY, "check resume data" on v4.5.5 is instantaneous, it "just happens".
In case it helps, i will put my 2 systems that i'm running qBittorrent below:
Main PC: qBt: v4.6.0 to v4.6.3 OS: Windows 10 Pro - 22H2 Storage: RJ45 direct connection to NAS over 2,5Gb NIC, unit mounted as "T:\" drive. Data: 4000+ torrents
Local media server running unRaid (this is "the NAS"): qBt: Docker 4.6.3-r0-ls307 and 4.6.3-r0-ls308 OS: Unraid 6.12.4 Storage: Locally linked "Share" form Host:"/mnt/user/Torrents/" to Docker:"/downloads/torrents/" Data: Same 4000+ torrents (i just finished migrating everything today)
Side Notes: Have been using the migration to do several tests, and it seems that part of the slowness in my main PC setup with NAS as local drive is caused by some kind of bottleneck caused by pairing qBittorrent with a NAS, when checking data if i monitor the NIC graph, it uses almost no bandwidth(less than a megabit/s, usually around 500kbps or less), but when "re-checking" files it uses as much as 1000mbps (around 100-120MiB/s) from time to time.
On the other hand, rechecking resume data with v4.6.X in the Docker with local storage took way less, but still a considerable amount of time(in order of 10s of minutes).
Edit: Forgot to mention that i migrated my torrent files to the NAS on v4.6.2 as i built it like 1-2 month ago or so, before that i had them stored in multiple local drives inside my main pc, and the wait time was "bearable" as it was taking around 10-20 min to finish all the resume data checking, which might be why not so many people are bothering to report it.
I write this to raise awareness about the problem, as it seems it has been going for months and there is almost no coments nor complaints about it.
mkieweg
qBittorrent & operating system versions
ver: 4.6.0 Mac OSX Sonoma 14.0 Macbook Pro 16 M1Max
What is the problem?
All I did was upgrade from 4.5.5 to 4.6.0 and tried to relaunch the app..... and the entire app is frozen in the old bug from yesteryear..... Checking Resume Data. on every. single. torrent.
had to force quit.
Re-installed 4.5.5 without changing ANYTHING else...and voila. Worked liked a charm.
Steps to reproduce
install 4.6.0 encounter bug force quit re-install 4.5.5 works fine
Additional context
had about 100-150 torrents in the que. most of them had already finished download except for maybe 1 or 2. so its not like a huge active number of disk reads or writes was happening.
Log(s) & preferences file(s)
No response