You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have searched the existing open and closed issues
Is your feature request related to a problem? Please describe
I've observed that, most of the time, Brazilian movies are wrongly identified as having Portuguese language instead of Portuguese (Brazil). This could cause "collateral effect" issues on the library, particularly for external tools that integrates with Radarr.
For example, when using Bazarr. Let's say I create a Portuguese (Brazil) profile in Bazarr, marking the option skip downloading subtitles when the movie is already in the language of the profile. If I have in Radarr a brazilian movie classified as having Portuguese language, Bazarr will trigger the download of the Portuguese (Brazil) subtitle (which wouldn't be necessary, since the language of the movie is in fact Portuguese (Brazil)).
Describe the solution you'd like
I'm not sure the best way to solve this, but what I thought was that Radarr's language parser could take into consideration the country of origin of the movie (metadata collected from TheMovieDB). This way, if a movie is from Brazil you could assume by default that the language is Portuguese (Brazil) instead of Portuguese.
Describe alternatives you've considered
I'm not sure if it is possible to give the country context to the Language Parser exactly. If that is not possible maybe Radarr could do a "post-process" outside of the Language Parser.
Anything else?
I was in doubt if I reported this as an issue or feature request. Since I thought about a possible solution, decided to report as feature request.
The text was updated successfully, but these errors were encountered:
This is going to be an issue, because TMDB and mediainfo for the file has just Portuguese.
I was afraid that was the case :(
My idea would be using the field origin_country from TMDB API (https://developer.themoviedb.org/reference/movie-details) to make the disambiguation. If the original_language from TMDB (or the audio stream of the file) is pt [Portuguese] and BR is in the origin_country list, we assign the language as pt-BR [Portuguese (Brazil)].
Here is an example of the output for the movie Bacurau (truncated to highlight only the relevant part of he response):
Request: https://api.themoviedb.org/3/movie/446159
Response:
Is there an existing issue for this?
Is your feature request related to a problem? Please describe
I've observed that, most of the time, Brazilian movies are wrongly identified as having
Portuguese
language instead ofPortuguese (Brazil)
. This could cause "collateral effect" issues on the library, particularly for external tools that integrates with Radarr.For example, when using Bazarr. Let's say I create a
Portuguese (Brazil)
profile in Bazarr, marking the option skip downloading subtitles when the movie is already in the language of the profile. If I have in Radarr a brazilian movie classified as havingPortuguese
language, Bazarr will trigger the download of thePortuguese (Brazil)
subtitle (which wouldn't be necessary, since the language of the movie is in factPortuguese (Brazil)
).Describe the solution you'd like
I'm not sure the best way to solve this, but what I thought was that Radarr's language parser could take into consideration the country of origin of the movie (metadata collected from TheMovieDB). This way, if a movie is from Brazil you could assume by default that the language is
Portuguese (Brazil)
instead ofPortuguese
.Describe alternatives you've considered
I'm not sure if it is possible to give the country context to the Language Parser exactly. If that is not possible maybe Radarr could do a "post-process" outside of the Language Parser.
Anything else?
I was in doubt if I reported this as an issue or feature request. Since I thought about a possible solution, decided to report as feature request.
The text was updated successfully, but these errors were encountered: