Allow searches to return partial matches

[Mushoz]

• I have checked the existing issues to avoid duplicates
• I have redacted any info hashes and content metadata from any logs or screenshots attached to this issue

Is your feature request related to a problem? Please describe

By default, Sonarr kicks of Season searches because they are way more efficient than episode searches. It's just one API call per season instead of one API call per episode. For some indexers, this works fine. When it searches for "<Show_name> s01" it will match "<Show_name> s01", but is will also match "<Show_name> s01e01". This means that if season packs are not (yet) available, Sonarr can pull individual episodes instead.

For other indexers, such as Bitmagnet, "<Show_name> s01" does NOT match "<Show_name> s01e1" because it does not allow for partial matches. In this case, when a season pack is not available nothing is downloaded. You'd have to manually kick off automatic episode searches either by clicking the search button for each individual episode OR by kicking off a search for all items in the "Wanted" list.

I know I can search for "<Show_name> s01*" instead, which WOULD also match individual episodes, but unfortunately that's not the way Sonarr sends out queries. I also do not know if all indexers support wildcards. So changing the search behavior downstream is probably a more risky approach.

Describe the solution you'd like

Allow for partial matches. Make is configurable if it's not desirable default behavior for whatever reason.

[Mushoz]

Would changing:

SQL: fmt.Sprintf("torrent_contents.episodes #> '{%d}' = '{}'::jsonb", s.Season),

to

SQL: fmt.Sprintf("torrent_contents.episodes ? '%d'", s.Season),

do the trick? I am not a go developer, but trying to understand the Torznab API endpoint and how it deals with the season parameter.

[mgdigital]

The Torznab API in bitmagnet allows searching either full seasons or individual episodes. If we do as you suggest then searches for season packs (where they DO exist) would be drowned out with individual episodes. AFAIK Sonarr also supports searching both individual episodes and full seasons, but if there's an issue to be fixed anywhere then I think it's a usability issue in Sonarr.

[Mushoz]

But Sonarr would still prefer (at the same quality) full seasons over individual episodes, so nothing is getting drowned out. While Sonarr does indeed allow searching for individual episodes, it's a manual and cumbersome process. When adding a new show for example, the initial search is always done as season searches. If you want to do episode searches, you will have to manually initiate those.

Furthermore, Huntarr also uses season searches when searching for missing content, upgrading existing content or when looking for replacements when blocking a stalled download. While Huntarr CAN be changed to use episode searches instead, then it's not doing season searches anymore as you can configure one or the other.

Changing multiple downstream projects seems far less feasible than changing the upstream indexer. And is there really a downside to such a change if it's configurable at Bitmagnet's level?

[mgdigital]

But Sonarr would still prefer (at the same quality) full seasons over individual episodes, so nothing is getting drowned out.

If you search for a full season and the result contains individuals (or more likely, is dominated by individuals because they are more in number), then it is most definitely getting drowned out.

While Sonarr does indeed allow searching for individual episodes, it's a manual and cumbersome process.

Exactly, so it's a usability issue in Sonarr. Bitmagnet has implemented the Torznab API correctly. Sonarr could fix this by following up with an individual episodes request when it sees there are no season packs.

[Mushoz]

But Sonarr would still prefer (at the same quality) full seasons over individual episodes, so nothing is getting drowned out.

If you search for a full season and the result contains individuals (or more likely, is dominated by individuals because they are more in number), then it is most definitely getting drowned out.

I understand where you are coming from, but since Torznab is an API which is processed by an application, having more results isn't really drowning out anything as long as the logic still prefers the actual season packs, which it does.

While Sonarr does indeed allow searching for individual episodes, it's a manual and cumbersome process.

Exactly, so it's a usability issue in Sonarr. Bitmagnet has implemented the Torznab API correctly. Sonarr could fix this by following up with an individual episodes request when it sees there are no season packs.

I agree, but it's what Sonarr is expecting from the indexers. Eg:
https://www.reddit.com/r/sonarr/comments/1l6l3xv/comment/mwq6o9v/
https://www.reddit.com/r/sonarr/comments/kxkxy8/comment/gjb9ibw/
https://www.reddit.com/r/sonarr/comments/10ueqrg/is_sonarr_expecting_individual_episodes_to_be/

You could argue that this is a wrong expectation to have, but for the end-user it does result in the experience being much better with indexers which do match individual episodes. Furthermore, while I understand your viewpoint, I also understand that Sonarr does not want a fallback to individual episodes, because suddenly 1 season is 30 API requests instead of just 1.

I understand it's probably better not to hardcode this, but make it configurable instead. And it should probably default to the current behavior. But is there really a big downside to at least making this configurable?

[mgdigital]

suddenly 1 season is 30 API requests instead of just 1.

So assuming Sonarr needs to find individuals for a 30-episode season with no full season pack available, IMO its best strategy is indeed to make 30 requests, after all that's what it makes its users do manually! Torznab specifies no standard way to do this in a single request, meaning it's swimming in a soup of miscellaneous episodes and might need to pull many pages of results anyway to happen upon a copy of every one meeting quality constraints. The Reddit comments you linked only confirm what I'm saying that this is an annoyance that Sonarr users will have to deal with in other indexers even if Bitmagnet added a workaround.

The Torznab integration will be moving to a plugin anyway when the next version is finally ready. I'll have a think about this issue but in any case users would be able to edit the plugin/make their own if they wanted to change the behaviour.

[Mushoz]

I brought up the discussion on the Sonarr reddit and two people related to Sonarr joined the discussion: https://www.reddit.com/r/sonarr/comments/1qvxw0r/season_search_does_not_return_results_for/

One argument was this:

The spec doesn’t indicate one way or another, what the expectation is, but the results should be inclusive for all results that match.

This should be no different than how a search for a series (without season and episode params) returns all results for that series and the same for searching by title.

Whether you agree or disagree with the reasoning isn't the most important thing. The thing is that the Torznab protocol was developed specifically for a standardized way of communicating with torrent indexers. While there are many different "Arr" applications, most of them don't even use the season parameter because they don't specifically deal with series. The most popular exception to that is of course Sonarr, which is specifically created to download series. And right now, Bitmagnet is not as useful for Sonarr as it could be.

From my discussions with the people surrounding Sonarr it's very clear they expect all season episodes to be returned when only searching with a season parameter, and they do not wish to let go of that expectation. Knowing that, what's the downside of making such a change in Bitmagnet? It's obvious it would improve Bitmagnet when used as an indexer for Sonarr. Which clients would this change be a downside for? Especially if it was an optional and configurable change?

[mgdigital]

You sound like you're trying to persuade me of something, which makes me think you didn't read my previous reply properly. I don't have anything more to add to that right now.

[Mushoz]

I did read your previous reply. I merely came back after my discussion with the Sonarr people to share their point of view. You mentioned that the Torznab integration would be moving to its own plugin in the future and you would have to think about this issue. So I wanted to give you all the available viewpoints for when you make that decision whether or not to change the behavior. The decision is obviously ultimately up to you.