Sonarr Newznab Search Missing Episodes

Help & Support
#1

Sonarr version (exact version): 2.0.0.5344
Mono version (if Sonarr is not running on Windows):5.20.1.34
OS: Linux
Debug logs:
Description of issue:

When searching for shows on a Newznab indexer, Sonarr seems to send 2 queries.

One query using

tvdbid=368126&season=2&ep=2

and another query with

q=Servant&season=2&ep=2

The problem is that if the indexer didn’t match the first query it most likely won’t match the second query either, even though it might actually have the episode.

The proper backup query should use

q=Servant+s02e02

At the time of this writing nzbgeek did not find anything relevant for:

https://api.nzbgeek.info/api?t=tvsearch&cat=5030,5040&extended=1&apikey=...&offset=0&limit=100&q=Servant&season=2&ep=2

But had good matches for:

https://api.nzbgeek.info/api?t=tvsearch&cat=5030,5040&extended=1&apikey=...&offset=0&limit=100&q=Servant+s02e02
#2

It may not have it indexed under the TVDB ID, which is why it falls back to the title, but it should have the season/episode numbers parsed.

Sonarr always sends season/ep params, it’s expected the indexer has parsed those titles and even if it hasn’t matched the release to a TVDB it knows which season and episode it belongs to.

#3

Yes, I realize that the indexer should probably be doing a better job at parsing the data, but why can’t Sonarr be a little more flexible and account for indexers that may have minor issues?

As a user, I have several options, none of them very good:

  • Change my indexer or add another. This costs money, and nobody is guaranteeing me that the new indexer will be any better.
  • Download missing episodes manually - this kinda defeats the purpose of having a robot do it.
  • Complain to my indexer and hope they fix it.

As a software developer myself, I can’t help but feel that as a automation tool, Sonarr should be doing it’s best to interface with indexers rather than insist they all be 100% complaint. Especially if the fix is trivial, as it seems to be in this case.

#4

I respectfully disagree… :slight_smile:
Garbage in (quality of indexer results) is garbage out (no episodes found in sonarr), so it’s better to fix this at the source.

#5

In that case, why does Sonarr execute the second query, the one where the indexer didn’t match the TVDB ID? The same argument applies here too. The indexer should have matched the ID.

In a perfect world, yes, all indexers would perform flawlessly. But in the real world, indexers are controlled by small independent groups and they come and go.

Relying on them to all be perfectly behaved is unreasonable.

IMO, this attitude is sacrificing the user experience for the sake of an unachievable ideal.

#6

IMO, this attitude is sacrificing the user experience for the sake of an unachievable ideal.

No, coz searching by S01E01 puts more strain on indexers. The whole idea of ‘indexers’ is to parse the titles and store the data in quick to search tables. Doing a freetext search is 100x more impactful of an indexer’s systems. Raising their operational costs needlessly.

A release Servant.S02E02.720p.WEB.H264-GGWP (22 Jan 2021 05:27:00 +0000), has no ‘season’/‘episode’ attributes in the result, which indicates an indexing error.
Same with Mr.Mayor.S01E04.XviD-AFG (22 Jan 2021 01:51:06+0000) and possibly more.

Please report it to nzbgeek staff, it could be specific to that date or a wider issue.

#7

So why does Sonarr execute the “q=Servant+s02e02” in addition to the “tvdbid=368126&season=2&ep=2” query?

Note that not only does it execute the less efficient query, it seems to execute it immediately, even before it receives results from the tvdbid query.

If Sonarr really didn’t want to allow for Indexer lack of compliance, it wouldn’t have issued this second query at all. After all, the indexer “should” have matched the id.

Also, if Sonarr really cared about not overloading indexers, it would only issue the second query after the first one failed to provided matching results.

#8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.