Why does Sonarr repeat the search upon download failure?


#1

Sonarr: 2.0.0.5252 (Docker)
OS: CentOS 7

NZBGet (usenet) and NZB indexers.

I’ve noticed this behavior with single episode and season search.

Sonarr initiates episode/season search with one or more indexers.
Indexers may return 100+ results for the season or episode.
Dozens of the results meet the download criteria - profile/language/filters, etc.
Sonarr sends download requests to usenet client.
A download fails and instead of using other results already received from the indexer Sonarr runs the same search again. If multiple downloads fail Sonarr keeps sending searches instead of using available results. The multiple searches are returning the same results.

When using indexers which may have API limits this cycle can run up the counter rather quickly.


#2

The simplest is the results aren’t cached. There is also the case where there are new results (more for recently aired episodes, but a concern regardless).

In general we don’t recommend relying on free indexers with low API limits, but we could still improve this behaviour at some point (no short term plans for it).


#3

That makes sense. Sonarr does behave like it’s not caching the results. I figured overhead could be reduced and efficiency gained if Sonarr cached and exhausted the results before searching again.

I use a mix of paid and free indexers to cover more bases along with NZBHydra. It was in the Hydra stats and logs that I noticed the multiple back-to-back searches for the same episodes each time a queued download could not be completed.

All in all Sonarr has been an excellent tool for the short time I’ve used it. Keep up the great work!


#4

The simplest is the results aren’t cached.

@markus101
Actually, they are ever since we started queueing stuff for when download clients were unavailable. That includes Fallback releases not rejected by other criteria. I’ve been meaning to look at the FDH search logic, but for that we need to know if a search was performed vs rss vs release push. Best would probably be to include the kind of grab in the history event and track it that way.
So yes, it’s possible to almost entirely eliminate FDH searches.


#5

Thanks for correcting, I forgot about that.