Problem
Fixes #1005. When a qBittorrent torrent contains files marked priority 0 ("Do not download") — set manually or by qBittorrent's Excluded file names setting — the import never succeeds.
/api/v2/torrents/files lists every file in the torrent, priority-0 ones included, and TorrentClientPathMapper.BuildQbittorrentSourceFiles turned all of them into SourceFiles. Priority-0 files are never written to disk, so in DownloadProcessingJobProcessor the on-disk check
files = [.. queueItem.SourceFiles.Where(File.Exists)];
if (files.Count == 0 || files.Count != queueItem.SourceFiles.Count) // never matchescan never match, the job exhausts its retries, and the download ends up blocked without importing. This is common in practice — community Excluded file names lists routinely drop *.jpg, *.nfo, *.txt, and sometimes whole audio formats.
Fix
Skip priority-0 files when building the qBittorrent source-file list and when resolving the content path, so only the files qBittorrent was actually asked to download are required on disk. An absent or non-zero priority is still treated as a downloaded file (older qBittorrent builds and torrents with no exclusions are unaffected), and the priority value is read tolerantly (number or string).
Scope note
The issue also described the download being left "Downloading" forever and failing silently. On current canary that part is already handled: when the processing job exhausts its retries, DownloadProcessingJobProcessor marks the download Blocked (with a LogError), and Blocked is not one of the statuses that keep automatic search from grabbing an alternative. So this PR targets the remaining root cause — the priority-0 count mismatch — so these downloads import instead of blocking.
Tests
Added to TorrentClientPathMapperTests:
BuildQbittorrentSourceFiles_ExcludesPriorityZeroFiles— only the priority-1 audio file becomes a source file; the e...
Automated Canary build