| Summary: | Sporadic GUI hangs when enough torrents are active | ||
|---|---|---|---|
| Product: | [Applications] ktorrent | Reporter: | ulterno |
| Component: | general | Assignee: | Joris Guisson <joris.guisson> |
| Status: | REPORTED --- | ||
| Severity: | normal | CC: | nicoadamo |
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
Seems to be correlating with Queue Manager as the workaround - Check "Control torrents manually" - seems to work. I'll try profiling the Queue manager. Realised while testing that during the period which the interface hangs, uploading also stops. Found a proper way to reproduce the problem. STEPS TO REPRODUCE 1. Have "Network->Maximum number of connection setups" value be much less than "Queue Manager->Maximum seeds" value 2. Have enough Completed and seeding torrents to make the set limits make a difference. OBSERVATION - Some part of the Queue Manager related processes block the GUI thread. Note, the fault would not cause a generally noticeable problem if the above steps are not used to magnify the problem. Still in version 25.08.0 I realized of this bug because of the different torrents start alternating (switching between active and paused or queued) at high speed. It seems the queue manager is not working properly with the option "Decrease priority of torrents which are stalled for more than " __ minutes. Forgot to mention that the number of tasks (mentioned in the status bar after the DHT number of nodes) keeps increasing non-stop, and CPU usage is increased as well (as a cap at a lower value, but it gets higher than the usual idle value). (In reply to Nicolás from comment #4) > Still in version 25.08.0 > I realized of this bug because of the different torrents start alternating > (switching between active and paused or queued) at high speed. It seems the > queue manager is not working properly with the option "Decrease priority of > torrents which are stalled for more than " __ minutes. This corresponds to GUI hanging when suspending/stopping a large number of torrents at once. The bug might have not been as easily visible, if stopping torrents didn't block the GUI (which on the other hand is ideal) So, apart from fixing the Queue Manager's algorithm, the GUI-backend separation for aforementioned operations would also need some work. Still in 25.08.2 - just tested. Still in 25.08.3 |
SUMMARY With enough torrents active, the amount of time when the GUI is unresponsive is significant enough to affect user experience STEPS TO REPRODUCE 0. Have enough active torrents (idk, maybe setup 400+ seeding at the same time, with multiple different and overlapping trackers) 1. Try to use the UI for long enough that you happen to be using it when the hangs happen OBSERVED RESULT - UI hangs for a few seconds at a time, then again and again, for ~1 minute of total time, after which it doesn't happen for a while - Also affects the System Tray entry's context menu EXPECTED RESULT - UI responds within humanly unnoticeable amounts of time SOFTWARE/OS VERSIONS KTorrent: 25.07.70 (master) KDE Frameworks: 6.14.0 Qt: Using 6.9.0 and built against 6.9.0 EndeavourOS (Wayland) Build ABI: x86_64-little_endian-lp64 Kernel: linux 6.14.6-arch1-1 Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 7600 ADDITIONAL INFORMATION UI hangs for a few seconds just before the debug output (not always, please read the end part): kf.kio.core: mimeType() not emitted when sending first data!; job URL = QUrl("***********announce***************************************************************************************************************************************************************************************************") data size = 0 then comes a barrage of similar messages, all for different URLs, all preceded by the GUI hanging for varying amounts of time. Following is another type of message that is part of the multiple debug messages that come up: kf.kio.core: mimetype() emitted again, or after sending first data!; job URL = QUrl("*******************announce*********************************************************************************************************************************************************************************************") kf.kio.core: mimetype() emitted again, or after sending first data!; job URL = QUrl("************scrape********************************") Interestingly, as far as I have seen, only 1 of the 2 types of messages come up for a given URL. Also, the said errors happen quite frequently, but the hangs don't happen every time, suggesting that the messages shown are not directly related. There seems to be some blocking event happening right before these messages, under certain conditions. I haven't used *.debug=true, considering it would just make it harder to find the problem, but if required, I can try.