Webchannel show not present in schedule API

Pete77 wrote 26 days ago:

The series is found in the full schedule: http://api.tvmaze.com/schedule/full

But using the schedule API with date the series can not be found:

http://api.tvmaze.com/schedule?date=2019-11-12

http://api.tvmaze.com/schedule?date=2019-11-15

http://api.tvmaze.com/schedule?date=2019-11-22

...

Am I doing something wrong? With other series it's working fine.


gazza911 wrote 26 days ago:

For the schedule endpoint, if you don't specify a country it will default to US.

As the Web Channel that show airs on - Disney+ - is marked as a global Web Channel it won't appear on the US schedule.

The full endpoint shows regardless of country, hence why it's present there.

Pete77 wrote 26 days ago:

So there is no possibility to filter that series by date? It's rather inefficient to get the full schedule because of the amount of entries.

Also in my logic should all global series included in US or any other ISO filter. If it's global, it does not make sense it's missing on any filtering.

Pete77 wrote 26 days ago:

Hm, ok. Thank you. I hope this will be fixed in the future. The API is great, but I (and many others too) can't understand this.


david wrote 25 days ago:

Moved to the API forums.

The schedule (on the site as well as in the API) only lists broadcast TV shows. The whole architecture of the schedule simply doesn't allow for webchannel "binge dumps" since it's not possible to list two episodes on the same combination of network+timeslot.

On the site this isn't much of a problem because tools such as the calendar or watchlist can be used instead. In the API, the full schedule endpoint has always been an acceptable fallback, but I agree there should be an easier way to retrieve these episodes with the ever increasing prominence of web channels. Let me think about this.


david wrote 25 days ago:

I have two ideas for exposing this in the API.

1. Create a whole new endpoint

e.g. /webschedule?date=2019-01-01 (all webchannel episodes on that day)
and /webschedule?date=2019-01-01&country=US (episodes from US-only web channels)
and /webschedule?date=2019-01-01&country= (episodes from global web channels)

2. Add a parameter to the schedule endpoint

e.g. /schedule?date-2019-01-01&country=US&web=all (broadcast US shows + all webchannel episodes)
and /schedule?date-2019-01-01&country=US&web=US (broadcast US shows + US-only web channels)
and /schedule?date-2019-01-01&country=US&web=global (broadcast US shows + global web channels)
and /schedule?date-2019-01-01&country=none&web=US (no broadcast episodes, US-only web channels)

I lean towards the separate webschedule endpoint (#1), since #2 has confusing semantics: the country parameter defaults to "US" while the web parameter would have to default to "none" to keep behavior for existing API clients unchanged and I don't want to introduce API versioning yet at this stage. The consequence is that you'd need two requests if you want the broadcast as well as the webchannel schedule though.

Thoughts?


gazza911 wrote 25 days ago:

We'd have to be careful with the new parameter.

Currently local Web Channels (I.E. US if the country paramater is set to US) are listed in the schedule endpoint.

We would have to imply that it's default the same as country if the Web parameter is omitted (to avoid breaking existing implementations).

If you wanted both global and US you'd have to make two separate requests.

Instead I'd propose that the parameter is just IncludeGlobal so that you'd always get local Web Channels and be able to get global if you wanted it.

Pete77 wrote 23 days ago:

Sorry for the late reply. I did not expect that somebody reply to this thread so fast (email notifications ftw).

Thanks a lot for your replies @david and @ gazza911. For me all options are ok.

But I understand gazza911's point to not break existing implementations. To prevent this an additional parameter would help. But more logical and much cleaner (in my opinion) is your 2nd option for me @david.

Pete77 wrote 16 days ago:

Any news about that topic?


david wrote 16 days ago:

For the time being I'm mostly waiting to see if there will be additional feedback.

.