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:
-
As RageTV is dead, why not use the query by default? Just setting “tvsearch” to “yes” now defaults to RID.
-
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);
- 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.
- No, if an indexer doesn’t properly handle the nn spec then it’s not our problem.
- 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 
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 :
- Search on tvmazeid
- Search on rid
- 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.
The main diff between this and true indexers is that true indexers identify individual releases and then put the ID in the database. Whereas you fetch a title somewhere (without alts) and then search your db using that title.
That’s going to be fine for most series, but those with alternative titles won’t work properly.
On the other hand, spotweb delivers a list of name’s and nzb’s which never can be discovered through other indexers. That is because the nzb / filenames have no relation with the true name except via the spotnet index. In that sense spotweb in unique. It is not a pure usenet indexer, but an indexer with data maintained by people.
Not as unique as you might think, but that’s irrelevant to the current discussion.
I’ve said what I needed to say about the api.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.