qBittorrent-nox CPU pinned at 100%; disappears immediately when qui is stopped

[gwenelmat]

Description

After running for a few minutes to ~30 minutes, qbittorrent-nox pins one core at 100% indefinitely. WebUI becomes unresponsive, trackers stop updating, only fix is restarting qBittorrent.
I used pidstat -t to identify a single anonymous thread responsible for the 100%. Attaching strace to it captured zero syscalls, so it's a pure userspace loop.
The interesting part: when I stop qui AND restart qBittorrent, it stays stable. As soon as qui is running again, the issue comes back within minutes to half an hour. qBittorrent alone stays fine.
My suspicion is the /sync/maindata polling. There's a related older qBittorrent issue (#10999) where that endpoint was found to be significantly slower and more CPU-intensive than /torrents/info, particularly with large collections. My situation may not be directly comparable (different scale, different hardware), but qui polling every 30s could still be enough to trigger something. There's also a separate Docker-specific qBittorrent bug (#23384) with libtorrent 2.0.11 showing similar symptoms, though the strong correlation with qui makes me think it's not just that.
Nothing unusual in Qbitorrent's logs.

Steps to reproduce

1. Run qBittorrent with ~200+ seeding torrents behind Gluetun in Docker
2. Connect qui to the instance
3. Wait — CPU spikes to 100% within minutes to ~30 minutes
4. Stop qui — CPU returns to normal immediately
5. Restart qui — issue eventually reappears

Environment

- qui: v1.14.1 (ghcr.io/autobrr/qui:latest, built 2026-02-23)
- qBittorrent: v5.1.4, libtorrent 2.0.11, WebAPI 2.11.4
- Docker (linuxserver/qbittorrent:latest) behind Gluetun (WireGuard)
- ~200 torrents seeding, single qBittorrent instance
- Linux host (Debian 13, kernel 6.18.9, x86_64)
- 2 active automations (one every 15 min deleting old torrent, one running every 6 hours calling an external script to restart containers)

Relevant logs

No response

Checklist

• I have searched existing discussions and issues
• I have checked the documentation

[jyggen]

Seeing this as well with qui v1.23.0 and qBittorrent v5.2.3 with 5k+ torrents. Checking pidstat of the qBittorrent process, running qui increases qBittorrent's average CPU from ~35.3% to ~76.6% (117% peak) and it's average %wait from 0.5% to 36.3% (60% peak). Not sure if it's due to /sync/maindata or not, but calling that endpoint directly through curl takes close to a second to return a response.