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:
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).
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.
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.
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.
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.
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.
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.
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.