Description
Re-scoped 2026-07-28 by DR-011.
This was "pull the monitored series list from Sonarr/Radarr — that is the crawl work-list". It is now an
optional pre-warm, because the work-list framing was wrong.
Checking how the comparable projects solve this: neither MediathekArr nor RundfunkArr reads Sonarr's
monitored series via the Sonarr API. MediathekArr is a live search proxy over MediathekViewWeb;
RundfunkArr uses curated shows.json / rulesets.json. Both are pure Newznab providers, because the
Newznab contract is pull-by-query: Sonarr already knows what it monitors and asks for exactly what it
wants via t=tvsearch&q=…&tvdbid=…&season=&ep=.
Two consequences:
- Reach-back is not required for the integration to work.
- Reach-back cannot satisfy search on its own — an interactive search for a show that is unmonitored,
or monitored but not yet crawled, returns nothing. Query-driven resolution is needed regardless (new
issue), which makes this an optimisation by definition.
What it is still genuinely good for: pre-warming the standing crawl list so the RSS feed has recent
episodes of the shows the operator actually cares about, without hand-curating a list the way RundfunkArr
does. That is a real UX win over the comparables — just not a prerequisite.
Scope
Usage Example
Alternative
Curate the crawl list by hand — which is exactly what RundfunkArr does and what Crawl:Targets already
supports. Perfectly workable; this issue only removes the manual step.
Notes
Description
Re-scoped 2026-07-28 by DR-011.
This was "pull the monitored series list from Sonarr/Radarr — that is the crawl work-list". It is now an
optional pre-warm, because the work-list framing was wrong.
Checking how the comparable projects solve this: neither MediathekArr nor RundfunkArr reads Sonarr's
monitored series via the Sonarr API. MediathekArr is a live search proxy over MediathekViewWeb;
RundfunkArr uses curated
shows.json/rulesets.json. Both are pure Newznab providers, because theNewznab contract is pull-by-query: Sonarr already knows what it monitors and asks for exactly what it
wants via
t=tvsearch&q=…&tvdbid=…&season=&ep=.Two consequences:
or monitored but not yet crawled, returns nothing. Query-driven resolution is needed regardless (new
issue), which makes this an optimisation by definition.
What it is still genuinely good for: pre-warming the standing crawl list so the RSS feed has recent
episodes of the shows the operator actually cares about, without hand-curating a list the way RundfunkArr
does. That is a real UX win over the comparables — just not a prerequisite.
Scope
IArrClient(added in Sonarr/Radarr instance config UI (Blazor) #4) with a monitored-series fetch: SonarrGET /api/v3/seriesfiltered to
monitored: true; RadarrGET /api/v3/movieequivalently.Crawl:Targetsentry must not disappear because an*arrinstance went offline mid-poll.*arrseries to a broadcaster show. This is the hard part, not the HTTP call: TVDB namevs. Mediathek topic name, german titles, aliases. RundfunkArr solves it with per-show curated
rulesets, MediathekArr with a filter/matching system. Expect the same investment here.
cycle or empty the list.
Usage Example
{ "Crawl": { "PreWarmFromArrInstances": true, // opt-in; default false "Targets": [ // still honoured, and never overwritten { "ProviderKey": "ard", "ShowQuery": "Extra 3" } ] } }Alternative
Curate the crawl list by hand — which is exactly what RundfunkArr does and what
Crawl:Targetsalreadysupports. Perfectly workable; this issue only removes the manual step.
Notes
IArrClient) — merged/in review.without this.
t=tvsearchwork forarbitrary shows.