The DownloadStation downloader left downloads stuck or silently failing.
This fixes the core flow and documents setup:
- Create the per-download destination folder via File Station (force_parent)
before creating the task; DownloadStation does not create it for a
direct-file task, which otherwise fails with "Destination does not exist".
- Auto-set the account's default destination when it has none (DSM leaves
every task "Waiting" otherwise), preserving the other server settings.
- Detect completion across the terminal states (Finished/Downloaded/Seeding/
PreSeeding or fully transferred), then verify the file is visible at the
container path before signalling success, so a path-mapping mismatch is a
clear error instead of a silent import failure.
- Surface DownloadStation errors (status_extra.error_detail, captcha) instead
of polling progress forever.
- Harden task-list / get-info / delete handling against responses that fail
to deserialize (upstream #723/#792) so one bad task can't abort a download.
- Make task creation idempotent: adopt an existing task instead of throwing
"already added", which previously bricked every retry.
Adds unit tests, fixes a settings description typo, and documents Download
Station setup and the path-mapping requirement in the README.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Applied to TorBox, can be extended easily to other providers
- Reads response headers commonplace for pre-emptive rate limit throttling and retry-after
- When a rate limit is reached, displays a warning in the UI
- Fix socket leak from direct allocation of HttpClient, replaced with factory which handles pooling and re-use of sockets.
While HttpClient is Disposable, it doesn't gaurantee (and does not) directly release underlying sockets for queries at the time the client is disposed. These sockets will go into a TCP WAIT state often for a very long time. The expected pattern in C# is to always use the HttClientFactory which will correctly handle re-use of the OS sockets in suqsequent queries reducing resource and memory leaks.
*Most* debrid providers know the filename as soon as they know the restricted links. By allowing them to tell the program this at an earlier stage, we don't need the `GetFileName` call for most debrid providers
