At some point in the past 2 weeks passing searches to Jackett has begun to fail.
When search results are returned we get a list of every show matching the Season and Episode numbers (capping at 150 results).
Looking at Jackett and Sonarr both have had at least 1 update in that time. I’ve tried rolling back Jackett to a build from early Jan, which made no difference. When I look at what jackett is doing, it is receiving search data that includes the TVRage id (rid=n) and the Season and Episode detail but it is then searching just on SnnEnn.
I have no logs from when this was working to compare, but right now I want to get it back to a working state. Rolling back Jackett was simple enough - the compiled binaries for past versions were there for DL, I’m struggling on the Sonarr end though - and more than that, I’m not sure I even should as Sonarr actually stores a bit of data whilst Jackett does not.
If I manage to get the previous compiled binaries, is it going to work with my current release version Sonarr database or am I clutching at straws?
Right. So not sure what happened, but I’m assuming it was related to Sonarr restarting after an update, though strangely the system itself has rebooted since the update.
In some desperation (after seeing hints that it is indeed the ‘rid’ TVRage element causing the problem, both on the forums here and in the Jackett issues) I restarted the Sonarr service twice from shell rather than the web UI. And now it’s working as expected once more.
I also found the backup restore wiki page (and more db backup files than it mentions, so I had plenty of options to roll back it turns out as long as I could find the binaries or compile my own).
Now everything is working again, it does leave me with the question: what happened?
When Sonarr talks to Newznab/Torznab indexers it checks the capabilities of the indexer and caches the result. If Sonarr failed to talk to Jackett (which implements Torznab) it may cache a default response and assume rid is supported. @Taloth was looking for logs to confirm that, I’m not sure if ((debug logs)) or ((trace logs)) would be required to investigate that further.