Re: New fields on JSON service: "totalSeason", "totalEpisodes", "awards", "duration", "episodeImage"

On 23 May 2016 at 04:31, Robert Kulagowski <[email protected]> wrote:
> On Sun, May 22, 2016 at 9:36 PM, Nick Morrott <[email protected]> wrote:
>> iv) I noted the following text on the SD GitHub wiki you linked to:
>>
>> "totalEpisodes: an integer indicating the total number of episodes.
>> Note: in an "EP" program this indicates the total number of episodes
>> in this season. In an "SH" program, it will indicate the total number
>> of episodes in the series. Optional.
>>
>> totalSeasons: integer indicating the total number of seasons in the
>> series. SH programs only. Optional."
>>
>> Based on the text in the totalEpisodes description, should the text
>> for totalSeasons state that it applies to only EP programs, rather
>> than SH as written?
>
> I believe that it's correct as written? Slightly further down in the
> wiki is an example of "Hot in Cleveland".
>
> programID "EP012599310061" has:
>     "metadata": [
>         {
>             "Gracenote": {
>                 "season": 3,
>                 "episode": 24,
>                 "totalEpisodes": 24
>             }
>         }
>     ],
>
> and
>
> programID "SH012599310000"
> has
>
>     "metadata": [
>         {
>             "Gracenote": {
>                 "totalEpisodes": 153,
>                 "totalSeasons": 6
>             }
>         }
>     ],
>
> So EP012599310061 is S03E24 (of 24 episodes in S03)
>
> SH012599310000 indicates that the series itself has 153 episodes, and
> 6 seasons. For an ongoing program, the SH program will be getting
> updated daily / weekly, but an EP type won't, because it's specific to
> that particular season.
>
> Does that help clarify things?

Absolutely :)

> One of my constraints if to maintain backward compatibility with the
> existing API for as long as possible; developers don't like APIs that
> are always jumping around, and I really tried to document the JSON API
> really, really well for developers.
>
> For the next API I might have more descriptive names like
> "totalEpisodesThisSeason" or "totalEpisodesThisSeries" for "SH"
> programs, but I want to avoid breaking existing applications wherever
> possible.

Thanks for the clarification. I'd misinterpreted the totalEpisodes as
"total episodes for the given season", rather than total episodes ever
made for the given title. That series-specific totalEpisodes figure is
something I've only ever seen on the Wikipedia page for a series of
interest.

>From the HiC wiki example, I was also wondering why totalSeasons
is/was not available in an EP record's metadata when it is known (i.e.
the series has concluded).

As such, the SH-specific version of totalEpisodes is not supported in
the DTD for current XMLTV grabbers, but the EP variant will dovetail
nicely.

The xmltv_ns scheme allows the grabber to inject details such as
episode W of X, of season Y of Z. Do grabbers typically return both
SHow and EPisode records for a given programme? If so, the
season/episode metadata split between both records could be combined
into a full xmltv_ns record.

Lastly, I have to ask - is the programme identifier component of the
programID computed via a hash/message digest algorithm? If so, is the
algorithm available outside of Gracenote?

Thanks again,
Nick

------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j