Error while searching serie episodes Rid

Hi,

I am having issues lately with my setup of Sonarr in combination with spotweb. (it has worked properly for months). Sonarr searches for an episode and i get this in the logfiles:

An error occurred while processing feed. http://127.0.0.1/spotweb/api?t=tvsearch&cat=5040&extended=1&apikey=&offset=0&limit=100&rid=38517&season=1&ep=1: Newznab error detected: No such item

I think the wrong error is caused by searching for the RID instead of the name of the serie. It has went well for months but last week it suddenly stopped…

Search will probably never work again, as spotweb development is next to dead.

Searches in spotweb rely on a real-time query to rageid. As rageid is dead, switching to other sources is needed. There are various sources that still can resolve the rageid to a series name, and sonarr had implemented searching on other parameters, but without alterations to the spotweb search engine, they won’t work. (Probably, haven’t tested the new search parameters yet as they only becane available yesterday in main).

Have the t=caps in spotweb return:

...
<search available="yes" supportedParams="q"/>
<tv-search available="yes" supportedParams="q,season,ep"/>
<movie-search available="yes" supportedParams="q"/>
...

That will let Sonarr know that you don’t support rid= and would like to get q= queries.
Please note that in the latest nn+ standard the supportedParams attribute is supplied as well, so apps can determine what the indexer supports.

2 Likes

Thanks, I’ll give that a go when I get a bit of time.

Edit: Can’t seem to get it to work.

I altered the spotweb “t=c” and “t=caps” responses to generate:

<searching>
<search available="yes" supportedParams="q"/>
<tv-search available="yes" supportedParams="q,season,ep"/>
<movie-search available="yes" supportedParams="q"/>
<audio-search available="yes"/>

To start clean, I disabled the current Spotweb indexer, and added a new Spotweb indexer.
When selecting manual search, the utilized url is still based on rid.

15-10-20 22:55:02.9|Debug|Newznab|Downloading Feed http://localhost/spotweb/api?t=tvsearch&cat=5030,5040&extended=1&apikey=&offset=0&limit=100&rid=30715&season=4&ep=1

I tried going through the trace logs to see if I could determine the capabilities discovery during the adding of the indexer, but I don’t see anything when searching on “spotweb” or “t=c” before it starts the search.

Restart Sonarr, we cache the caps response for 7 days in memory.

Ah, I figured adding a new indexer would bypass that.
On reboot and for the 1st search I do see the caps request.

15-10-20 23:17:17.7|Trace|HttpClient|Req: [GET] http://localhost/spotweb/api?t=caps&apikey=
15-10-20 23:17:17.8|Trace|HttpClient|Res: [GET] http://localhost/spotweb/api?t=caps&apikey= : 200.OK (40 ms)

And that was the end of it. No mention anymore on the search itself, and when going back to Settings - Indexer and test it, it’s giving:
Indexer does not support required search parameters
Unable to connect to indexer, check the log for more details

Additional searches only indicated my other indexers.
Searching 3 indexers for [Arrow : S04E01]

Time for bed, I’ll double-check if I made any typo’s tomorrow.

I indeed messed up, I was ending up just feeding text instead of creating the XML element supportedParams.

It’s working, but 2 questions remain:

  1. As RageTV is dead, why not use the query by default? Just setting “tvsearch” to “yes” now defaults to RID.

  2. Is it possible to just support “q” and aggregate the season and episode into the query? As said, Spotweb development is dead, and therefore the new newznab standard hasn’t been implemented. A “q,season,ep” search will result in all serie name hits, and therefore providing incorrect episodes.

If I now just add “q” instead of “q,season,ep” I don’t get any failures adding the indexer, but it won’t be utilized in the searches after retrieving the “t=?caps”.

For Spotweb reference, here’s the code that needs to be altered in SpotPage_newznabapi.php (I running a old branch, so can’t update github).

…/spotweb/lib/page/SpotPage_newznabapi.php around line 658 in the official branch.

            $search = $doc->createElement('search');
            $search->setAttribute('available', 'yes');
            $search->setAttribute('supportedParams', 'q');
            $searching->appendChild($search);
            $tvsearch = $doc->createElement('tv-search');
            $tvsearch->setAttribute('available', 'yes');
            $tvsearch->setAttribute('supportedParams', 'q,season,ep');
            $searching->appendChild($tvsearch);
            $moviesearch = $doc->createElement('movie-search');
            $moviesearch->setAttribute('available', 'yes');
            $moviesearch->setAttribute('supportedParams', 'q');
            $searching->appendChild($moviesearch);
            $audiosearch = $doc->createElement('audio-search');
            $audiosearch->setAttribute('available', 'yes');
            $audiosearch->setAttribute('supportedParams', 'q');
            $searching->appendChild($audiosearch);
  1. Because some indexers will use the old spec, and what should we switch to? tvdbid= or tvmaze=? spot web won’t support that, so the argument is moot.
  2. No, if an indexer doesn’t properly handle the nn spec then it’s not our problem.
  3. Sonarr requires (*id or q)+season,ep for t=tvsearch, we won’t fall back to q= only. This will not be changed.

I have added this line in my spotweb and it works again:) Thank you all for helping:)

I wasn’t specifically looking at Spotweb, as I’ve seen other indexers also struggle with the new standards.

My chain of thought, without any data to support it… I would guess most indexers would support a default query. In other words, make q the default instead of rid. If the indexer supports the new standards, they would probably have an updated caps which provides supportedParams and you can overrule the standard option.

True

K, not a biggie, automatic search will already sort out the garbage in the parser, so it only affects manual searches on indexers not using the updated standard.

I added some code to /spotweb/lib/page/SpotPage_newznabapi.php which seems to enable “q,season,ep” searches.

Please note, I’m on a old branch, and the code differs in the current version. It might need some tweaking for the current version.

Basically, it’s a 1-on-1 copy of the available RageID code, but if parameter is “q”, set tvSearch directly instead of resolving it by RageID, and then follow the rest of the season / ep handling, resulting in a combined search.

Around line 163, before the music search insert

            } elseif (($this->_params['t'] == "t" || $this->_params['t'] == "tvsearch") && $this->_params['q'] != "") {
		$tvSearch = $this->_params['q']; 
		$epSearch = '';

		if (preg_match('/^[sS][0-9]{1,2}$/', $this->_params['season']) || preg_match('/^[0-9]{1,4}$/', $this->_params['season'])) {
			if (strlen($this->_params['season']) < 3) {
				$epSearch = (is_numeric($this->_params['season'])) ? 'S' . str_pad($this->_params['season'], 2, "0", STR_PAD_LEFT) : $this->_params['season'];
			} else {
				$epSearch = $this->_params['season'] . ' ';
			} # else 
			} elseif ($this->_params['season'] != "") {
			$this->showApiError(201);

			return ;
		} # if
		if (preg_match('/^[eE][0-9]{1,2}$/', $this->_params['ep']) || preg_match('/^[0-9]{1,2}$/', $this->_params['ep']) || preg_match('/^[0-9]{1,2}\/[0-9]{1,2}$/', $this->_params['ep'])) {
			$epSearch .= (is_numeric($this->_params['ep'])) ? 'E' . str_pad($this->_params['ep'], 2, "0", STR_PAD_LEFT) : $this->_params['ep'];
		} elseif ($this->_params['ep'] != "") {
			$this->showApiError(201);

			return ;
		}	
		# The + operator is supported both by PostgreSQL and MySQL's FTS
		$search['value'][] = "Titel:=:+\"" . trim($tvSearch) . "\" +" . $epSearch;

Mesa57 has made an up-to-date Spotweb fork, for those of you who don’t want to tinker yourself, of want to check an up-to-date codebase to make your own changes.

  • Corrected the newznab category errors resulting in unwanted results in 5030 and 5040;
  • Support for resolving the RageID on TVMaze re-enabling RID searches;
  • Support for q,season,ep searches;

I’m seeing if he’ll also incorporate the supportedParams and enable searching on tvmaze id, which should be a quick fix now that he’s made the TVMaze handler.

Just commited the last changes. The version from my repo supports the following parms :
rid, tvmazeid, q, season, ep
These are returned on the caps command.

Episodes rageid is used to get the name via TVMaze.
Thanks to Mirx_NL contribution :smile:

You’re probably better of not exposing rid as supportedParams. the tvmaze db of rageids is limited compared to what Sonarr has.

If you’re keeping both rid and tvmazeid, then you should swap around the if statement to give tvmazeid priority. (Sonarr will query ?t=tvsearch&rid=123&tvmazeid=123&season=1&ep=1). In real indexers, the id is looked up with OR operator.

Could you provide me with a link to the latest NN+ standards ?

There isn’t an updated one. Or at least not publicly accessible.
But there aren’t many differences from the last one.

Sonarr is not the only client, so I need support for the rageid as well.
It would make life easier if you could share the newest NN+ standards.

I wasn’t being clear apparently: I don’t have an updated one. I don’t have a newznab subscription.

I didn’t say you shouldn’t support rid when queried, I suggested you don’t advertise it as supported. So apps not yet supporting the new spec, and thus blindly query by rid, will function normally. While apps that do support the new spec will use tvmazeid or q instead.

I think it would be better to specify all parms as supported on the caps command.
However, if multiple specified on the the call, there should be a priority.
So what do you suggest ? My proposal :

  1. Search on tvmazeid
  2. Search on rid
  3. Search on q

?
[edit] No answer, so I have changed it and committed it like above [/edit]

I would indeed prioritize tvmaze over rageid, as that seems to be more future-proof.

As for the importance and priority if q I’m not sure.

Reason is, I’m not to sure what Sonarr utlizes for show name resolution, and what they put in the q query.
So from Sonarr perspective, it might be a unneeded webquery to tvmaze to resolve the showname, as it might be identical to what Sonarr puts in the q parameter (which doesn’t need additional webcalls to resolve the name).

From a broader perspective, resolving it indexer side on an id will always give the same result, not depending on what the client happens to put in the q parameter.

As Spotweb acts as a generic indexer, I would prioritize similarity in result over additional web calls, and thereby place q last.

Maybe @Taloth can pitch in his thoughts, as he has the most experiance on how the “web” indexers handle things.