I am ignoring the environment session given that the issue I am raising is related to the tracker search engine.
BJ-Share has a very peculiar (maybe fragile) search engine, when you search for SERIE_NAME EPISODE they do not return any result. But if you search for SERIE_NAME you can find the episode in the results.
I am no sure if this is a problem that we want to solve on Jackett level, I am using pyMedusa and they have their own implementation of BJ-Share that kind of works.
Is there a way to translate jacket's incoming request to be a query that only has serie name, and filter the results based on episode name Or Episode number?
No error
In the first query I search for Star Trek Picard and I am able to find S01E10
If I change the query to Star Trek Picard S01E10 I can't find anything
Another example is
I could go on and on, but basically the problem is that it's doesn't work consistently
@eduardomoroni Are you able to provide an invite to a C# developer?
perhaps @DarkSupremo or @christianfds can provide an invite or even contribute as they both have since Dec 2019
It's done already, but maybe it's another problem... i'll take a look tomorrow.
private string StripSearchString(string term, bool isAnime)
{
// Search does not support searching with episode numbers so strip it if we have one
// Ww AND filter the result later to archive the proper result
term = Regex.Replace(term, @"[S|E]\d\d", string.Empty).Trim();
return isAnime ? term.TrimEnd(_digits) : term;
}
Tested it today, and it seens to be working fine, maybe you can explain exactly what problem you're experiencing?
It already strip the season and episode from search and filter it later (it may cause problem if the result is not on the first page, but it's the only way for now on BJ-Share), the season and episode letter must be in uppercase to be striped correctly.
I implemented the searcher for BJ-Share on pyMedusa, it use the same regexp and logic...
This is an search running directly in Jackett:
Thanks @DarkSupremo for looking into this issue.
As you state if you manually search on Jackett it works fine, I don't know the difference but seems like when it's an external query (not UI) something is odd.
App logs can be found here: https://pastebin.com/2i2rAEcf
I tried to use both pyMedusa and Sonarr, similiar error happened to me.
This is the log I receive when Jackett receives a query from and external app
2020-04-12 10:58:17.7963 Info Found 0 releases from BJ-Share for: Star Trek Picard S01E10
and this is the log I receive when I manualy query (using jackett UI)
2020-04-12 11:08:15.1424 Info Manual search for "Star Trek Picard" on bjshare with 3 results.
The query I do is "Star Trek Picard S01E10"
My guess is that through manual search we strip off the S01E10
before querying, then we run the query with Star Trek Picard
and search for S01E10
in the results. But when it's not a manual search we just search for Star Trek Picard S01E10
.
The logs might be non-accurate as well.
@eduardomoroni Are you able to provide an invite to a C# developer?
If needed yes,
Tested it on sonnar (v3) and it's working fine, maybe it's some wrong configuration or filter applied on it?
04-12 14:33:16 Info Found 3 releases from BJ-Share for: Star Trek Picard S01E10
Changed the regex that strip the Season / Episode to be case insensitive, i don't think that it's the case, but just a try (pull request waiting for approval)..
Also, make sure your Jackett is updated aswell..
Tested on pyMedusa here and it worked fine aswell, but in the case of Star Trek: Picard, i had to add an Scene Exception as "Star Trek: Picard 2020", because pyMedusa didn't parsed it propely.
This is an case to post as an bug on pyMedusa repo...
The reason all results return the year after the name, is because this indexer (bj-share) don't have an conditional year that is usually present when the serie is an remake, so all tv shows that had another show with the same name in the past would not work otherwise...
Found some problems related to group options turned off, could you try enable it in bj-share options and check if it solve your problem? i'll look into that...
@DarkSupremo I appreciate your help. I believe we can close this issue.
cheers