Skip to content
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

Question Help with improving Jackett Qbittorrent query #14855

Closed
1 task done
swannie-eire opened this issue Nov 17, 2023 · 4 comments
Closed
1 task done

Question Help with improving Jackett Qbittorrent query #14855

swannie-eire opened this issue Nov 17, 2023 · 4 comments
Labels

Comments

@swannie-eire
Copy link
Contributor

Is there already a request for your feature?

  • I have checked older issues, open and closed

Is your feature request related to a problem? Please describe.

This is Question about the Qbittorrent plugin which i believe was created by one of the jackett devs.

https://github.com/qbittorrent/search-plugins/blob/master/nova3/engines/jackett.py

I noticed recently that the results coming back from the qbittorrent jackett plugin can be different that what you get from jackett UI or jacket API.

using jackett api url and query with just single indexer(retroflix) - i get one result which is correct and same i get when i do manual search via UI.
http://10.0.0.125:9117/api/v2.0/indexers/retroflix/results?apikey=API_KEY&query=tt0097176

qbittorrent jackett plugin url and query with just single indexer(retroflix) - i get zero result which is correct.
http://10.0.0.125:9117/api/v2.0/indexers/retroflix/results/torznab/api?apikey=API_KEY&q=tt0097176

Now i can see that jackett api returns in JSON and qbittorrent plugin returns in RSS. I assume the queries here "q" vs "query" are the same or are they searching different fields and hence the different results. Is there a pros and cons to using API search before i implement a plugin using the JSON response.

Another off topic question.
This is just a question for now. I will open a FR request depending on answer.
If a imdb_id is in entered to search does jackett auto recognise this as an IMDB_ID number due to the "tt" at the start and then search the indexer or all indexers using the param "imdb_id=tt0097176" or does it still just query the search field of that indexer with whatever string is being entered.

If it does identify it as IMDB number and searches just the IMDB_ID field then is is possible for it detect and search for a TMDB/TVDB number. I know TMDB/TVDB just use number for IDs so it impossible to know what the ID is for but if i enter something that tells it that its TMDB could jackett detect it and then search for the TMDB ID. e.g if i entered TMID:0000001 into search would jackett recognize this as TMDB id and search the TMDB ID
instead of searching indexer search field?

Describe the solution you'd like

An answer to why the results are different and the best option going forward. I rarely use jackett UI and do all my searches with qbittorrent plugin so want it to be as accurate as possible.

Describe alternatives you've considered

none

@ilike2burnthing
Copy link
Contributor

Torznab search requires imdbid= to perform an IMDB ID search. You can see more about the search modes and parameters here - https://github.com/Jackett/Jackett#search-modes-and-parameters

The non-torznab search path, the same as is used by a UI search, can identify a keyword query starting with ``tt` and followed by 7 or 8 numbers, and then perform an IMDB ID search.

For some indexers (e.g. TheRARBG) this makes no difference, as the search path is the same for both and there's no search setting which needs to change (e.g. searching title or description). However, for others (e.g. RetroFlix, or more specifically the SpeedAppTracker abstract it's based on), there's a difference, and you're now performing a title keyword search for an IMDB ID (which obviously isn't going to return anything):

if (query.IsImdbQuery)
{
qc.Add("imdbId", query.ImdbID);
}
else
{
qc.Add("search", query.GetQueryString());
}

@garfield69 do you know if detection of an IMDB ID keyword for a torznab search was intentionally not added, or if it was just something that never got implemented?

@swannie-eire feel free to open an FR for UI searching by the parameters linked above.

@garfield69
Copy link
Contributor

do you know if detection of an IMDB ID keyword for a torznab search was intentionally not added, or if it was just something that never got implemented?

It was not added because detecting an imdbid as a word of the search query is not a torznab specification, only the imdbid parm is supported as per spec.

The use of imdbid on the GUI search was a customization that was added so that the dashboard search field could at least provide an imdbid lookup in lieu of the dashboard not having additional GUI fields for searching imdb, tvdb, tmdb etc.
And only imdb was added because obviously a tmdb/tvdb number could not be told apart, where as tt1234567 was unique enough to id it as imdb.

@swannie-eire
Copy link
Contributor Author

do you know if detection of an IMDB ID keyword for a torznab search was intentionally not added, or if it was just something that never got implemented?

It was not added because detecting an imdbid as a word of the search query is not a torznab specification, only the imdbid parm is supported as per spec.

The use of imdbid on the GUI search was a customization that was added so that the dashboard search field could at least provide an imdbid lookup in lieu of the dashboard not having additional GUI fields for searching imdb, tvdb, tmdb etc. And only imdb was added because obviously a tmdb/tvdb number could not be told apart, where as tt1234567 was unique enough to id it as imdb.

Thanks for response. any idea why torznab was used for the qbit plugin instead of the API?

@ilike2burnthing
Copy link
Contributor

Because it's an RSS feed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants