GUI unresponsive during torrents loading

[tristanleboss]

qBittorrent & operating system versions

qBittorrent: all Operation system: Windows 10 (10.0.1xxxx)

What is the problem?

What I don't understand about qBt, irrevelant of the version, is why the UI is unresponsive in the first place. It's super important to have a responsive UI even if the program is struggling with a task. It's not very common to have a hanging program like qBt.

For example, when I start qBt, it takes half an hour to load my 7k torrents and, during all this time, the window is just blank. If, for some reason, it's too hard to do that, at least, show a loader: "Torrents loading: X out of Y..." I think doing a glob(BT_backup/*) and getting the count of unique hashes is probably really quick and would really help the user because you don't even know if the program is stuck or doing something unless you check the log files.

https://docs.microsoft.com/en-us/windows/uwp/debug-test-perf/keep-the-ui-thread-responsive

Steps to reproduce

Put a lot of torrents in qBt.

Additional context

No response

Log(s) & preferences file(s)

No response

[thalieht]

It's vastly improved in master. Wait for 4.5.0 or try alpha builds if you're feeling adventurous and aren't on some private tracker that whitelists client versions. https://github.com/qbittorrent/qBittorrent/actions/workflows/ci_windows.yaml?query=branch%3Amaster

[tristanleboss]

Yes, I wrill try this 4.5.0 version.

Indeed, my qBT 4.4.4 RC_1_2 was unresponsive for 4 hours after my IP v6 was renewed at 12:25 ("Successfully listening..." lines in the log file). At 17:17, I isolated it from Internet using Windows Firewall. It does nothing fancy, no huge read/write operations (I check using the Windows Performance Monitor because some read/write operations are done by "System" not only the qbittorrent.exe process). At 17:30, it did a big burst of write to flush all the fastresume files to disk. At 17:50, I removed the block from Windows Firewall. Downloads/Uploads instantly resume but GUI is dead. At 18:40, the GUI is suddenly back eith exactly the same I/O stats. At 22:00, it's gone again (nothing suspicious in the log).

During all this time, qBt struggles. The downloads and uploads seem to continue for most the time in the background. Activity shown by the log file seems lighter than when GUI is working: there is not as many events (I am used to have lot of events because I have a rule to pause torrents after their ratio reaches 1) as when the GUI is alive. I even get Windows notifications sometimes when a torrent has completed: it briefly updates the GUI and refroze. The move operations are sometime working, sometime not, they can stay on "Moving..." forever even for a small PDF file. That's why I cut the network most of the time because, when I do so, at some point, the move completes.

It looks like it's struggling... but my disk are lightly used during these time (7% according to process manager). SMART data are perfect. No error logged in Windows Event Viewer. It doesn't seem to be a bottleneck issue. Memory usage is the same. Every metrics are identical when GUI is dead or alive.... And it worked for 5 days without troubles.

I am clearly used to it now ;)

[linhuijie663]

Yes, I wrill try this 4.5.0 version.

Indeed, my qBT 4.4.4 RC_1_2 was unresponsive for 4 hours after my IP v6 was renewed at 12:25 ("Successfully listening..." lines in the log file). At 17:17, I isolated it from Internet using Windows Firewall. It does nothing fancy, no huge read/write operations (I check using the Windows Performance Monitor because some read/write operations are done by "System" not only the qbittorrent.exe process). At 17:30, it did a big burst of write to flush all the fastresume files to disk. At 17:50, I removed the block from Windows Firewall. Downloads/Uploads instantly resume but GUI is dead. At 18:40, the GUI is suddenly back eith exactly the same I/O stats. At 22:00, it's gone again (nothing suspicious in the log).

During all this time, qBt struggles. The downloads and uploads seem to continue for most the time in the background. Activity shown by the log file seems lighter than when GUI is working: there is not as many events (I am used to have lot of events because I have a rule to pause torrents after their ratio reaches 1) as when the GUI is alive. I even get Windows notifications sometimes when a torrent has completed: it briefly updates the GUI and refroze. The move operations are sometime working, sometime not, they can stay on "Moving..." forever even for a small PDF file. That's why I cut the network most of the time because, when I do so, at some point, the move completes.

It looks like it's struggling... but my disk are lightly used during these time (7% according to process manager). SMART data are perfect. No error logged in Windows Event Viewer. It doesn't seem to be a bottleneck issue. Memory usage is the same. Every metrics are identical when GUI is dead or alive.... And it worked for 5 days without troubles.

I am clearly used to it now ;)

I had a similar GUI unresponsive problem before, it got fix after I change the network interface option from "any interface" to the one my pc actual use, and I use IPv4 address only.

[tristanleboss]

@linhuijie663 Yes, I discovered that too and, indeed, at the time I changed the setting, it improved.

But, it's not enough. Finally, after 6 days, I had to kill the process 4.4.4 RC_1_2 because I didn't manage to bring it back to life. When it's stuck for good, the memory is changing from simple to double every seconds. I did a video...

https://user-images.githubusercontent.com/1431508/187607497-8cdf5881-7ecd-4dd7-be40-b32e2c233768.mp4

The private bytes memory was 1.4 gb during the first day. 6 days later (today), when I killed it, it was 5.4gb. Yesterday, it was 4.0gb. The torrents were the same during the whole period.

[xavier2k6]

Thank you for your contribution, we are starting to close all old/stale/obsolete tickets.

Please update to latest qBittorrent 4.6.5 ATTOW.

If any issues are experienced, please open a new ticket.