[niddelicious]

Summary

Added functionality to make download clients eligible/non-eligible for different media type (determined by index search), making any grab filter out any clients not enabled for the grabbed type.
Priority field for download clients is enabled in frontend and after filtering any eligible client is processed in priority order.

Origin for this feature was my personal need to pass books to one Transmission instance and audiobooks to a different Transmission instance.

Checklist

• Commits signed off with git commit -s — see Sign your work
• Tests added or updated
• docs/DEPLOYMENT.md updated if env vars, config, or upgrade path changed
• Added a changelog fragment under changelog.d/ (not an edit to CHANGELOG.md) — see changelog.d/README.md
• Wiki pages updated if user-facing behaviour changed

Test plan

• make check (or the individual go test ./cmd/... ./internal/... and cd web && npm run build steps)

[codecov]

Codecov Report

❌ Patch coverage is 84.07960% with 32 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
internal/scheduler/scheduler.go	78.84%	8 Missing and 3 partials ⚠️
web/src/pages/settings/ClientsTab.tsx	46.66%	5 Missing and 3 partials ⚠️
internal/api/queue.go	83.33%	3 Missing and 3 partials ⚠️
internal/api/download_clients.go	78.57%	2 Missing and 1 partial ⚠️
internal/db/downloads.go	0.00%	3 Missing ⚠️
web/src/api/core.ts	50.00%	0 Missing and 1 partial ⚠️

📢 Thoughts on this report? Let us know!

[vavallee]

Thanks for this, it's a nice feature and the routing itself is solid: both send sites filter, polling and removal still go by client id, the migration is safe, and the tests pass. A few things turned up in review that hit exactly the setups this is for, so I'd like to get them sorted before merging.

Needs fixing

1. Readarr import creates clients that are eligible for nothing. internal/migrate/readarr.go around line 268 builds a models.DownloadClient without the two new flags, so they go in as false and every grab afterwards fails with "no enabled download client is eligible". Setting both to true there (or defaulting in repo.Create) fixes it.
2. Approving a pending release sends audiobooks to the ebook client. internal/api/pending.go around line 180 uses the book's media type, which is both for a dual format book, and FilterEligibleForMediaType treats anything that isn't audiobook as books. The pending release row has its own MediaType; using that routes it correctly. That bug predates your PR, but the eligibility filter is what turns it into a misroute.
3. SendWithFallback can send the same release to two clients. It moves on after any error, but several errors happen after the first client already accepted the download: Transmission returning id 0, qBittorrent with no hash, SABnzbd with no NZO id, or a timeout reading the qBittorrent response. The torrent then lands in both clients and the first copy is never tracked. I'd either drop the fallback (use the top ranked eligible client and report its error) or only fall through on errors that prove nothing was sent, like a connection refused before the request.

Worth doing here or as a follow up

4. Auto-grab doesn't look at the other protocol. scheduler.go around line 1031 picks the best release across both protocols first, then gives up if that protocol has no eligible client. With SABnzbd set to ebooks only and qBittorrent to audiobooks only, a usenet audiobook that ranks best means the sweep logs "no eligible download client" and ignores the approved torrent, every sweep. Filtering candidates to protocols that have an eligible client before choosing would fix it. The manual grab error also tells you to "enable a download client for audiobooks" when one already exists for the other protocol.
5. Grabs from the free-text Search page always count as books. Results there have no media type, so an m4b torrent found on /search goes to the ebook client. Book detail and Wanted are fine because they fall back to the book's type.
6. Priority now sorts ahead of the category hint in RankClientsForMediaType. That's reasonable, but it can change which client an existing install uses, so a line in the changelog fragment would help.

Housekeeping

• The red CodeQL check isn't you. Those three alerts are already open on main at the same lines; CodeQL blames this PR because the client URL input moved in download_clients.go.
• 086 collides with other open PRs (#2607, #2626, #2628). Whichever lands later renumbers, so no action yet.
• This will go into v1.37 rather than a patch release.

Happy to help with any of these if you get stuck.

[vavallee]

Heads up on a migration number collision, not a review.

This PR adds a migration numbered 086, and so does #2673 or #2633, whichever this is not. Both are open and both claim it. assertUniqueMigrationVersions (internal/db/db.go:685) refuses to boot when two files share a numeric prefix, so whichever merges second breaks startup for anyone with both.

086 is a genuine gap on main, which goes 085 then 087, and it has never been filled by a merged commit. Three separate branches have each created their own 086 at some point, which is how the gap became attractive to all of them at once.

Main tops out at 089. Current claim map across the open PRs:

• 086 → feat(author): drop thin edition clusters from catalogue sync (#2235) #2673, Feature/download client media eligibility #2633
• 090 → feat(api): auto-approve requests per requester account (#2718) #2761, feat(indexer): normalise the audiobook size bonus by runtime and cap grabs (#2740) #2750, feat(downloader): remove the torrent after a successful import (#2046) #2713
• 091 → fix(scheduler): stop a failed queue row blocking an automatic re-grab (#2710) #2714
• 092 → feat(quality): rank releases by profile order, best first (#2733) #2737
• 093 is the first genuinely free number

Suggest renaming to 093 or above rather than reusing the gap, and picking the number by checking open PRs rather than main. The reason this keeps happening is that each branch computes "next free" against a main that excludes everyone else's in flight work.

[niddelicious]

Check, I'll look into your comments.

I also missed the workflow tests and just went with the app tests, so I'll see if I can get the workflows locally so we don't need to fail the actions EVERY time I think I've got it.

[vavallee]

Hey @niddelicious, checking in on this one. The branch now conflicts with main, so it needs a merge of main (a plain merge is fine, no rebase needed).

On the migration: 096 is free on main and nobody else has claimed it, so you can keep that number.

I haven't re-read your 09-29 commit against the review yet. Once the conflict is sorted I will, so it would help if you could say which of the six points from the review it covers (the Readarr import flags, the pending release media type, the double send in the fallback, auto-grab across protocols, the Search page, and the changelog line).

If you're short on time, no worries. If I don't hear back by 2026-10-31 I'll pick it up from your branch and keep you credited as the author of the feature.

[niddelicious]

Thank you for your patience @vavallee
I merged main into the branch via plain merge

I do believe I've fixed all the issues you mentioned, or rather my buddy Claude did:

1. Readarr-imported clients are eligible for both books and audiobooks by default.
2. Pending grabs use the pending release’s media type, with a fallback for older rows.
3. A failed send is reported without trying another client, since the first client may already have accepted it.
4. Auto-grab filters releases to protocols with an eligible client before choosing a result.
5. Free-text Search infers media type from the release and sends it with the grab.
6. The changelog fragment notes that priority now precedes category hints and may change which client is selected.

I had a look and it seemed like 116 would be the next migration, so I picked that.