media: bypass qbit_manage's qBittorrent version ceiling #383
No reviewers
Labels
No labels
audit-work
bug
docs
general-admin
major-upgrade
needs-vps-sync
new-service
on-hold
outside-work
post-podman
renovate
upstream
vps
No milestone
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
mysticalsoap/docker!383
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/qbit-manage-version-check"
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?
Problem
qbit_manage v4.13.0 only accepts qBittorrent up to 5.2.3 (a version compare against its bundled
qbittorrent-api). qBittorrent moved to 5.2.4 on 2026-10-01, and every scheduled run since 2026-10-02 00:00 exited at that check withCRITICALbefore running a single command. No alert fires on that path (webhooks.erroris empty by design), so it went unnoticed for six days: 26 torrents added since then had no tracker tags, including every bookshelf-audio torrent, and no share-limit or unregistered cleanup ran.Fix
skip_qb_version_check: trueinmedia/qbit_manage/config.yml, with a comment on why. Setup page gets the gotcha and the "check the next run reachedExecuted Commands" step after a qBittorrent bump.Verification
Live, 2026-10-07, with the edited config bind-mounted:
docker exec qbit_manage python3 qbit_manage.py --runlogged the[BYPASS]warning and completed. Afterwards every torrent is tagged (661 of 661, previously 643 of 669 with the 26 untagged all added after 2026-10-01); the eleven bookshelf-audio torrents carryMyAnonaMouseorIPTorrentsby announce host; nine torrents whose library copy is no longer hardlinked (five movie upgrades, four albums) receivednoHLand thenoHL-iptorrentsshare limit, and eight torrents were removed by the catch-up cleanup.🤖 Generated with Claude Code