Jump to content

TMDB - Bug fetching episodes info from TMDB


anderbytes

Recommended Posts

anderbytes

Hello, I noticed that when Emby tries to fetch episode metadata from TMDB and there's no title metadata for my language (pt-BR), it uses the whole filename as title, instead of fallbacking to English.

 

Can you reproduce it?

Link to comment
Share on other sites

What happens is that Tmdb doesn't fallback the language. We have to send a separate http request to get the english data, and if we do that for every episode in the library users are going to complain about slower scan times.

Link to comment
Share on other sites

I'm a bit confused about this thread: When the TMDB provider is querying episode data, it's using the series id, season number and episode number.

In which situation would it use an episode title to query information from TMDB?

Link to comment
Share on other sites

I'm a bit confused about this thread: When the TMDB provider is querying episode data, it's using the series id, season number and episode number.

In which situation would it use an episode title to query information from TMDB?

 

What he's saying is that the TMDB title comes back null so the server just uses the file name for display.

Link to comment
Share on other sites

OK, got it!

So he must have disabled all other metadata providers that are either "English only" or internally fallback to English information.

Maybe we should implement some ultimate very last fallback to "Season x - Episode y"..

Link to comment
Share on other sites

One more note before getting too excited about having a fallback mechanism in the TMDB API.

Actually such a fallback is something that we would not want to happen for Emby providers! 

 

Here's why: When we query a provider for a certain language and we know that the provider doesn't do any fallback, we can be sure that the returned data is in the requested language. If the provider would implement fallback to English or another language, we would never know the actual language of the returned data (could even be mixed in a worst case).

 

In a configuration with multiple providers this could result in situations where an English title or overview is used although another provider would have localized data.

 

(this is even true while another improvement for localized content hasn't been included yet: https://github.com/MediaBrowser/Emby/pull/1731)

Link to comment
Share on other sites

anderbytes

But @@anderbytes, if you want fallback, just activate any of the other episode providers...

The whole idea of enabling just one provider came because Emby started spitting lots of errors when different providers diverged in content.

 

Example: tmdb says that show has 6 Seasons, but in thetvdb someone already inserted season 7, or if in tmdb a season finale is counted as one big episide but thetvdb separated in 2 episodes.... Also I dont know if the fact that only tmdb has season metadata is confusing with series and episodes metadata from thetvdb, that used to be my priority.

 

 

Maybe the right thing to do was to report the Emby errors related to this difference in providers. If fallback is too hard, I'll activate thetvdb again and report them

Link to comment
Share on other sites

Season metadata is a totally separate thing and shouldn't have any side-effects.

Also, we don't use any "season count", just episode infos. If one provider has information for a certain episode but another doesn't have yet, we take the info from the first provider.

But when episodes are counted differently at providers, yes, this could cause problems...

 

@@Luke, correct?

Link to comment
Share on other sites

anderbytes

@@softworkz, I'm just waiting for next stable (bringing the DLNA rework) , hoping it will diminish the qty of errors in logs.

 

After that... I'll focus on posting logs that have errors related to this topic.

Link to comment
Share on other sites

  • 1 month later...
anderbytes

Season metadata is a totally separate thing and shouldn't have any side-effects.

Also, we don't use any "season count", just episode infos. If one provider has information for a certain episode but another doesn't have yet, we take the info from the first provider.

But when episodes are counted differently at providers, yes, this could cause problems...

 

@@Luke, correct?

 

I guess those scenarios where the count of episodes is different should be considered in the future.

Link to comment
Share on other sites

I guess those scenarios where the count of episodes is different should be considered in the future.

 

What do you mean? Where is the count of episodes an issue?

Link to comment
Share on other sites

anderbytes

What do you mean? Where is the count of episodes an issue?

Some time ago I used to activate more than 1 metadata provider at a time. Then some strange errors started to appear...

 

I took some time to understand that the shows (always shows, never movies) who had different counts of seasons or episodes between providers were the ones that were causing errors.

 

As usual, the best way of explaining is with examples. So today I'll install latest beta and set some providers On for shows metadata. I'm pretty sure I'll be having those errors again soon.

Edited by anderbytes
Link to comment
Share on other sites

  • 3 weeks later...
anderbytes

Well yea probably because sometimes they do not agree on season/episode numbers.

 

Imagine this scenario:

- TheMovieDB is enabled as Season metadata downloader (there isn't any other to choose)

- TheTVDB is the episodes metadata (because, let's say, I don't trust TheMovieDB for TV shows info)

- TheMovieDB says there are 6 season of a show, but only 5 are in TheTVDB because it's more controlled there when it enters

 

Isn't this an example of something that could bring some chaos? I remember that the logs were full of errors related to "Season X, Episode Y not found..." or something like that

 

 

 

I haven't had the time yet to retest the multi-provider scenario, to bring the logs here.

Link to comment
Share on other sites

Yes, it can bring chaos. Instead of expecting us to handle that situation, I would suggest just not doing it. Perhaps in the future we'll just have you choose one or the other.

Link to comment
Share on other sites

anderbytes

Yes, it can bring chaos. Instead of expecting us to handle that situation, I would suggest just not doing it. Perhaps in the future we'll just have you choose one or the other.

 

So with that you said.... I only have 2 options.

- use only TheMovieDB as an episode provider, along TheMovieDB season provider

- or completely disable season provider metadata.

 

I actually can do one of those and avoid the errors. But stil.....this situation SHOULDN'T happen.

 

Server should know it's own limitations and at least warn us with big red letters, or else make us choose ONE provider for SERIES+SEASONS+EPISODES at a time

Edited by anderbytes
Link to comment
Share on other sites

 

 

or else make us choose ONE provider for SERIES+SEASONS+EPISODES at a time

 

 

Yes, that's exactly what we should do.

  • Like 1
Link to comment
Share on other sites

Yes, that's exactly what we should do.

 

I don't think that such a radical measure is required. I got all series/season/episode providers enabled (tested with quite a number of series) and there are just very rare cases where problems occur like those described here.

 

IMO, the solution for this is a feature that we've discussed a number of times before:

 

Allow overriding providers for single library items would be a much better solution:

This would solve the problem described in this thread and also the problems where a certain provider is better suited for a certain language.

Link to comment
Share on other sites

anderbytes

I think it is not about if it is radical or not. It is about integrity of data: if it is possible that a specific set of configurations may lead to errors, why allow it in first place?

 

About your suggestion: if would be a "per library" configuration, it would be a matter of time to each TV library has at least one show in this situation, and in long term, all of TV libraries would have this activated, so why bother ?

 

Another solution would be some kind of check inside emby code to avoid throwing errors and treating the cases with notifications to admin, or maybe don't throw errors and period.

Edited by anderbytes
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...