From Many Feeds to One Candidate Set
Sonarr can only make a useful decision after it has a useful set of candidates. This chapter examines how Sonarr treats indexers as capability providers, fans RSS and explicit searches out across the providers that can perform them, normalizes the results, and removes duplicates before policy evaluation. The key judgment for the reader is to separate two responsibilities: an indexer can report releases, but Sonarr still owns the question of which reported release should be acted on.
That distinction prevents a common misunderstanding. If an indexer returns a release, it has answered a retrieval question: “What does this source know about?” Sonarr still has to determine whether the release names a known episode, whether it is in scope, and whether it is a better choice than competing results. Discovery expands the evidence available to the application; it does not grant permission to download.
An indexer is a capability provider, not the selector
Sonarr's indexer contract describes what a provider can do. An indexer reports whether it supports recent RSS fetching and whether it supports search. It exposes operations for several kinds of criteria, including single episodes, seasons, daily episodes, anime episodes, and specials. It also supplies a download protocol and a request for retrieving an individual release.
The contract is intentionally narrower than Sonarr's overall workflow. It does not decide whether an episode is monitored, whether the release quality meets a series preference, or whether an existing file should be replaced. Those questions depend on the series and episode state already held by Sonarr. The indexer's output is a ReleaseInfo-style candidate: a title, size, publication date, links, protocol, source identifiers, and provider metadata that later stages can interpret.
This boundary makes different providers interchangeable at the level that matters. A provider can use its own API, feed format, or query language internally. Sonarr receives the same broad kind of result and applies the same downstream identity and policy machinery. The abstraction does not make providers equivalent in quality or reliability. It gives Sonarr a stable place to handle their differences.
The provider base class performs part of that normalization. It removes duplicate results by GUID and attaches characteristics such as the provider identity, protocol, configured priority, and search-age limits. These values are not decorative. Without provider identity, Sonarr could not explain where a candidate came from. Without protocol, it could not match the candidate to an enabled download path. Without a GUID, it could not reliably recognize the same report when several sources expose it.
Provider definitions also carry capability flags. One indexer may be enabled for recent-feed monitoring but not automatic search. Another may support interactive search but have no usable RSS path. This is a more accurate model than a single “enabled” switch because different workflows impose different demands on a provider.