-
Notifications
You must be signed in to change notification settings - Fork 231
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
[Jimaku provider] Search fails because of year in title #2704
Comments
Thank you for reporting! First at all AniDB ban will be strictly printed on the Logs as "Banned" status and it will be throttled for 24 hours. Also if you use this HTTP Client only bazarr the AniDB, bazarr is very strict on respecting 190 requests per day and strong cache to prevent rate limit. Secondly, Jimaku does not uses the anidb API and only the Github XML mapping as you pointed out. So the above comment wouldn't be an issue even if you are banned. |
By any chance, do you have any time to help investigating this issue, i believe there are 2 things: 1 - Just quickly check why the mapping didn't work? The logs seems to contain the anime name and the ids necessary to investigate. |
Yeah I will look into it if there is some free time! |
Sorry for the late response, I should figure out why GH doesn't notify me when I'm mentioned somewhere... Regarding point 1: I see that no Regarding point 2: The fallback name is assembled as
That said, we could make this fallback a bit more robust though. No show has 2024 seasons (except maybe One Piece in a few years :P) |
@sdaqo I believe if you use the same naming scheme of episode 4 for episode 1 then you'll be able to match subtitles again. Seeing as guessit is an external module, we can only raise an issue regarding this inaccuracy in their repository (whose last commit was 10 months ago 🤔) |
Yeah i see, it is indeed related to the filename, there are even some other similar cases like this guessit-io/guessit#774. |
All the media is managed by sonarr so naming should be the same?
The parent folder is named: I also noticed something weird in the api response for the episodes, for ep 4 and 5 (the ones that work properly) the field "sceneName" is null, is this maybe a hint?
I also tried running the filenames through guessit:
Episode 4:
This seems correct to me? |
Hmmm, I feel like your ep1 log has shown a different file?
Note the filename: That one is using a naming scheme that yields higher guessit accuracy. |
@ThisIsntTheWay That is why I think the api call I attached has something to do with it. What exactly is the "scenceName" property? Ok, I know that this is the original filename before being modified by sonarr, but where exactly does bazarr pull this from and why is there no "sceneName" for episode 4/5? Edit: Edit 2: Just to be clear, the file shown in the logs ( |
It's a bug I've seen a couple of time in Sonarr. They simply do not keep it so we cannot reuse it. |
Well, bazarr being fed a phantom path is new to me 🤔 Either way I'm not really sure why you're being trolled and I'd need to investigate further. |
Well, yes, but this file is in a completely different directory. Ok so I also checked a little bit and first of all as @morpheus65535 said, the sceneName property in sonarr is not populated for episode 4/5 in this case: I scoured the bazarr code a little bit and this line in the "get_video" function is probably the "cause", as the name of the path which is passed down to the guessit call gets alteredt to the "sceneName" here. That said, there is probably a good reason why this happens, but maybe something could be adjusted there. |
This is the expected behavior. We use the scenename to provide more informations about the original filename before the users strip them all to have something nice and clean to look at... |
@morpheus65535 This makes sense, but in this case the modified filename has more info. Now, how can it figure out which of the names is better suited for parsing? I do not know, but since bazarr is already calling the sonarr/radarr api, why not get the info from there instead of the filename? |
Because their API doesn't provide as much info as we get from the original filename. |
Is there anything left to fix here? I read the whole conversation again and I'm still not sure if something should be done... |
Until guessit-io/guessit#774 is solved, how about a checkbox in the settings (e.g. in the sonarr settings) that forces the system to always use the current filename. I, for example, almost always have more info in the current filename then the original and considering Sonarr is so inconsistent when it comes to populating the scenename property I think it makes sense to have such an option. |
But anyway, if there's no scenename provided by Sonarr, Bazarr will use the filename instead so I'm not sur of the benefit here... |
Yeah that's what I mean, I think it would be beneficial because such an option would always use the filename instead of the scenename. That would be more consistent as sonarr should always name the files in the same way and the user can tweak it themselves. I am aware that the scene name is necessary for some lookups (e.g. someone uploaded a subfile with the exact same name as the scene name), but as this is only for the info extraction I think it would make sense. Moreover there are providers, like jimaku that relies on the extracted information, and I think giving the user the option here would make sense. |
…ining it with scene name if available. #2704
I've modified Bazarr to use both when available. It will now guess using file name first then, if available, guess using the scene name. We should get the better of the two worlds with that. Let me know if upcoming beta improve your results. |
Awesome, that sounds like a perfect solution, will test it as soon as I have time. |
No news, good news! |
Describe the bug
Hi there! I am currently trying to use the jimaku provider, but I am having some problems. If the anidb/anilist refiner does not work, i.e. it is not able to extract a anilist ID for whatever reason, the provider (jimaku) will try to search by name. When it is searching by name however, the year is always included (e.g. Alya Sometimes Hides Her Feelings in Russian 2024), this is problematic, because the jimaku api will not give us any results as it does not expect any year numbers in the title.
I assume the reason why the ID can not be extracted sometimes is some kind of ANIDB ban, I hear they are notorious for their ancient rate limiting. Besides that I found an odd case where it did find an anidb ID but only for episodes 4,5, this happened for "Alya Sometimes Hides Her Feelings in Russian". I will attach some log files, but this issue is probably not related.
Another assumption would be that it does find an anidb id but is not able to match it to a anilist one (I asssume you are using this for mapping: https://github.com/Fribb/anime-lists), this could of course also result in no anilist id. That said, I think analyzing this is out of scope here.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
I expect the jimaku provider to remove the year when searching.
Software (please complete the following information):
Additional context
Here are some logs:
I want to point out line 44 in this one:
Here we can see it searches by anilist id:
The text was updated successfully, but these errors were encountered: