e83b661471
Live testing surfaced: every download attempt failed with 'Torrent client refused the URL', but qBit was actually accepting the add request fine. The bug was in our hash-lookup strategy. qBittorrent's /api/v2/torrents/add returns 200 'Ok.' regardless of whether the URL was actually valid / accepted / registered. The previous code then queried /torrents/info?category=soulsync to find the just-added torrent — but qBit hadn't categorised the new torrent yet on the first poll, AND a fresh install has no 'soulsync' category configured, so the lookup returned empty and the adapter reported failure for every working download. New strategy: - Snapshot every torrent hash qBit currently tracks BEFORE posting to /add. - POST /add, accept its (uninformative) 200 OK. - Poll the all-torrents list for up to 5 seconds, looking for a hash that wasn't present in the before-snapshot. First new hash wins. The diff strategy works the same for /add with urls= (HTTP URL / magnet) and /add with files= (raw .torrent upload), so both paths now share the same _all_hashes + _poll_for_new_hash helpers. Adds a warning log when qBit returns an unexpected body and an error log when no new hash appears (so future investigation has breadcrumbs). |
||
|---|---|---|
| .. | ||
| __init__.py | ||
| base.py | ||
| deluge.py | ||
| qbittorrent.py | ||
| transmission.py | ||