Hi matherrien,

Yes, as per the TV preview thread, the primary outstanding tickets are the change methods. They might be completed this week but for sure by the end of next.

Cheers.

Any updates for tv changes?

Not yet, but the ticket is still open. It will be getting looked at soon.

I've also been holding back on the development of my tv shows usage, waiting for the tv changes routines

I've considered going forward and implementing tv shows beforehand but the season/episode logic differentiate tv shows from movies heavily

For example I just send one api call to update the movie information, however this logic wouldn't work for tv shows as re-parsing all seasons might be an overkill

So I wonder how the changes syntax is going to be, a separate tv show/season/episode change methods could solve the issue, or there might be additional info at the changes routine to see what exactly changed But I'm guessing the preferred method would be to parse the tv/tvshow_id/changes after detecting a change to the tvshow_id to see what exactly changed

Still, separate show/season/epside change methods might simplify complete synchronization routines a lot

Hi kaansoral,

TV is a little bit different in that we try to bubble up the season and episode changes to the series with a change entry. You can see that here, on 24.

There will be separate methods for each show/season/episode.

The one main thing that I will say in advance is that I am pretty sure this is where the season and episode "id" will come in to play. I haven't completely designed this but I think I'll be using those id's to link everything since each resource needs to be treated uniquely.

If I am not making any sense think of it this way, if someone deletes an episode but then later re-adds it, do we point the changes to the same place? I'm thinking no, since a new record was created. We want to keep the fact that a resource was deleted and re-added discrete therefore, we need to count on the ids.

In any case, I am planning on this next. It was on my list for this coming week but I ended up having to take a few days off so we'll see if I finish it by Friday.

Cheers.

I do get what you are saying generally, I've also used the thetvdb before, so I'm a bit familiar with the unforeseen issues caused by the episode id's / adding / removing episodes / seasons - things can get ugly

I'm generally looking at things from the API user perspective, I hope I'm not out of my way, and I hope I can provide a useful view

There are currently /3/movie/changes /3/person/changes methods, It would be a great idea to have /3/tv/changes /3/season/changes /3/episode/changes as new methods (Not every episode change needs to trigger a change in the season, not every season change needs to trigger a change in the tv show, but they also may, doesn't matter too much)

Those who are building not too detailed systems might choose to just tap into /3/tv/changes /3/season/changes - as season data also includes a lot about the episodes (only episode "id"'s is missing as I see http://docs.themoviedb.apiary.io/#tvseasons)

I would rather prefer to bubble up the changes myself, instead of parsing the tv changes, going to the season changes, and pulling the episode that changes, it would be much much easier to parse the episode change from the /3/episode/changes - and bubbling the change up to whatever the internal structure is

So if the /3/tv/changes /3/season/changes /3/episode/changes system exists, I wouldn't parse the /3/tv/{id}/changes - I would rather just parse the basic /3/tv/{id} data - and the season/episode changes would find their way through /3/season/changes /3/episode/changes automatically

When an episode gets deleted, as an API User, I would detect it from both /3/season/changes /3/episode/changes - update the season and episode entities accordingly, disabling the deleted episode entity

(Off topic, I'm not exactly sure how to implement the episode/id persistence internally, with the thetvdb that was the main problem, a lot of casualties occur, someone might comment on an episode, but if the episode id gets changed, all that data gets lost, the comment/action gets orphaned etc. so it would be great if the episode ID's would be persisted as much as possible in the design of the TV feature --- let's say the order of 2 episode's are wrong, instead of deleting them both and re-adding, maybe the orders can be changed, the id's would persist --- it might be possible if the order's would be determined automatically from weights, getting sorted and adopting #1, #2, #3 as episode numbers etc.)

Hi Travis,

I noticed you implemented the changes call for series now but seem to be running into issues on occasion. From time to time I get the following error: {"status_code":6,"status_message":"Invalid id: The pre-requisite id is invalid or not found."} I don't get it when using either movie or people so I think there might be something going amiss.

Regards

I'm almost done with TV changes, still working on a few things.

What call are you making that is producing the 404 error?

/3/tv/changes, not consistently giving the error, other changes calls are stable

A few of the API servers didn't pick up the deploy from this morning. I'm not sure why, but that's why you're seeing it randomly—whichever requests are being sent to that server doesn't have that endpoint live.

I'll be doing another deploy in a bit and will double check every server gets the new code (this has never happened before, at least not that I'm aware of).

Cheers.

All API servers should now be running the updated code. Let me know if you see this again.

P.S. this has officially launched, you can catch up on it here.

Thx for the great work!