-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] Switching search type from TVSEARCH to SEARCH unnecessarily (and only for external requests) #842
Comments
Please create and post the debug infos zip. |
In 2021 NZBGeek as well as nzbplanet did not support t=tvsearch without ID keys (e.g. tvdb ID). That seems to have changed. I can only verify for nzbgeek but if you tested it with nzbplanet I'll take your word for it. So to be clear, The internal search does not change the type because you can see that using the autocomplete IDs were provided ( |
nzbplanet:
Regarding the internal search, I don't fully understand. Why did hydra send this query: |
Sorry, that was wrong. Previously nzbplanet did not support t=tvsearch without ID keys so hydra switched to t=search (search ID 32498 in the log). For search ID 55558 in the log , that's apparently a bug. When a fallback query is requested the fact that tvsearch is (supposedly) not supported with a query is ignored. But as the indexers all seem to support that this bug is fixed as well. |
Makes sense, thanks for looking into this! |
Is what hardcoded? The way the API is implemented by indexers is all over the place. An indexer may support TVSEARCH but only when used in combination with IDs or not support season/episode parameters for regular searches or whatever. Previously those indexers mentioned above allowed TVSEARCH when used in combination with an ID but not when used in combination with a query. They seem to support that now which is why I removed the extra handling for them. |
the capabilities of the indexer or why do you have to change the searchtype for a special indexer urself. |
Yes, that special part was hardcoded. There are so many special cases that I don't want to check for them each time. |
But it should not be used when the user can use the capability check :/ |
This info is part of the capabilities though. I'm starting to agree with @reloxx13, there shouldn't be a need for hardcoding indexer-specific behavior. That being said, I have no idea how much time it would take to implement this instead of changing some hard-coded values every once in a while. nzbgeek:
nzbplanet:
Both list "q" as supported parameter in tv-search queries. |
I've seen that one indexer (nzbplanet) returned way too many results from a generated query after an external request.
This is the log:
All indexers except nzbplanet found 0 results because the season hasn't aired yet.
Interestingly, the queries for nzbplanet and NZBGeek have been switched to SEARCH, supposedly because the queries aren't supported by the indexers.
I've tried it out and both nzbplanet and NZBGeek are totally fine with the TVSEARCH query (0 results for season 5 and lots of results for season 4).
nzbplanet returned 196 results because it completely ignores the season attribute if the search type is not TVSEARCH.
It gets more interesting: an internally triggered web-search doesn't change the query type and behaves correctly:
This only shows the log for nzbplanet but the same is happening for NZBGeek.
The text was updated successfully, but these errors were encountered: