Ditto, but for Seasons ?

We do not have any plans on introducing that as a query end point at this time. Episodes can be deleted and re-added (which would be a new id). Because of this, you can only query by the combination "season number" and "episode number". That is the public "id" if you will.

The id is only useful when tracking changes via the changes API.

Cheers.

I have recently moved my app to utilize the TV show data away from TheTVDb site, however I have run into this issue of non-unique IDs for the episodes. My app requires the ID's to be unique so that the episodes can be added to iTunes with a unique content ID. The other site's ID were unique so was never a problem. But now after switching the app over I've noticed that iTunes is seeing the content as different versions of the same thing. If no plans exist to provide a unique ID for these types of scenarios, any suggestion on how best to handle this use case utilizing the current non-unique episode ID would be appreciated.

Take Care.

HI dynamicrealms,

Episodes do have unique IDs, you just can't query with it. But having said that, as per my point above and that the combination "season number" and "episode number" being the "id", would that not work for you? Ie. lets use season 7, episode 1 of Castle as an example:

https://api.themoviedb.org/3/tv/1419/season/7/episode/1?api_key=###

It has the id of 1000953. But could you also not make the id something like "S07E01"? "S07E01" will always point to the same proper resource.

Hi Travis,

Thank you for your quick response.

If I take a similar example similar to yours... say "Breaking Bad": https://api.themoviedb.org/3/tv/1396/season/1/episode/6?api_key=###

I get back an episode ID of: 62090

However if I take that ID and put it back into a TV show query: https://api.themoviedb.org/3/tv/62090/season/1/episode/6?api_key=###

I get back a TV show called "I Live with Models"

If I take that same ID and perform a movie search: https://api.themoviedb.org/3/movie/62090?api_key=###

I get back the movie "blink-182: The Urethra Chronicles"

I'm assuming this also means that potentially another TV show would also have an episode ID of 62090, or are those truly unique within the global space of TV episodes?

For my apps (one for movies and one for TV shows), the user potentially could end up with conflicting content IDs (which are supposed to be globally unique). Your idea of using the SxxExx as a possibility is a very good one, unfortunately Apple and iTunes expect the content ID to be a number only and will not recognize anything else.

I was considering using something like "99"+seriesID+episodeID (99139662090), such that I push the content ID to a very large number with a recognizable prefix, but I see this as kind of a hack, not to mention it could run the risk of too large a number. It is possible to leave out the content ID altogether in the tagging and iTunes will have no issue, but one then loses the ability for iTunes to recognize multiple resolutions of a video such as SD or HD. iTunes will see the two files as two distinct TV shows one as SD and one as HD instead of a single show of HD-SD.

Thanks again.

All ID's within a media collection will be unique but indeed, they are not unique outside of their own media type. There is only 1 episode with the ID of 62090. There is only 1 movie with the id 62090. One show, one person, one movie, etc... Once an object has been deleted the ID is never reused (this is why we have so many ID holes).

If you're forced with integers, coming up with a pattern with some padding and appending the ids like you described is probably next best thing.

Hi, sorry it's been a long time since my first post but I came back here because I really think the API route GET https://api.themoviedb.org/3/tv/episode/{episode_id} is important and useful.

For instance I am storing comments about a specific episode in my database using this object: {media: 'episodes', media_id: 1337}. I am doing the same for every media type and this works well because my code stays the same for any media type.

As mentionned before storing episode references as show_id + season + episode is an ugly hack. That's what ids are for.

You mention that "Episodes can be deleted and re-added" but I'd hazard a guess that is also true for movies and tv shows.

Best, John

@travisbell said:

We do not have any plans on introducing that as a query end point at this time. Episodes can be deleted and re-added (which would be a new id). Because of this, you can only query by the combination "season number" and "episode number". That is the public "id" if you will.

The id is only useful when tracking changes via the changes API.

Cheers.

It might be nice to soft delete things that may be re added. That info could be useful in other ways.
If ID=1234, which is Season7 Episode8, gets deleted, it would be nice to have "Deleted=true" as a column in the response. If the episode gets re-added just toggle to Deleted=false and ID=1234 is still valid. Plus we could report in a UI that "S07E08 is no longer available" easily. I do agree in your other comment that to derive the GET params needed while still maintain your own unique id in a proprietary schema is doable.

Now that I think about it a bit more... It might be bad to soft delete it. If the title is bad (for example), you would want to hard delete so misinformation doesn't persist

@shostream said:

Hi, sorry it's been a long time since my first post but I came back here because I really think the API route GET https://api.themoviedb.org/3/tv/episode/{episode_id} is important and useful. For instance I am storing comments about a specific episode in my database using this object: {media: 'episodes', media_id: 1337}. I am doing the same for every media type and this works well because my code stays the same for any media type. As mentionned before storing episode references as show_id + season + episode is an ugly hack. That's what ids are for. You mention that "Episodes can be deleted and re-added" but I'd hazard a guess that is also true for movies and tv shows.

Hi, I'm sorry too it's been a even longer time since first post but I agree with shostream.

@travisbell said: We do not have any plans on introducing that as a query end point at this time.

If there is no plan to implement direct access by episode ID maybe it's possible to add it to /find/ID?external_source=tmdb_id endpoint?
It seems to be easier use IMDB IDs for clients now then TMDB, and it's a little strange.

Happy a New (2024) Year.

@rysson said:

@shostream said:

Hi, sorry it's been a long time since my first post but I came back here because I really think the API route GET https://api.themoviedb.org/3/tv/episode/{episode_id} is important and useful. For instance I am storing comments about a specific episode in my database using this object: {media: 'episodes', media_id: 1337}. I am doing the same for every media type and this works well because my code stays the same for any media type. As mentionned before storing episode references as show_id + season + episode is an ugly hack. That's what ids are for. You mention that "Episodes can be deleted and re-added" but I'd hazard a guess that is also true for movies and tv shows.

Hi, I'm sorry too it's been a even longer time since first post but I agree with shostream.

Not so long since rysson post, but I agree with both rysson and shostream. In my particular case, as I maintain 'To watch' lists, I have to use IMDB id to recover details (from TMDB) for episodes if needed, which is quite an improper hack, as it makes depend on external sources.

Best regards.