RE: ACTION-33 and ACTION-35: API additions to remianing requirements

Hi Sean

Passing some series identifier from the application to the UA seems to be the right way forward for the given requirement in which a program has metadata indicating it as being part of a series.
It is not very likely that any consumer electronic EPG data will contain program/schedule information for more than 2 weeks ahead of the current time (the network/broadcaster probably knows what episode of what program in a season they will schedule)
What the UA does with it is entirely implementation dependent (it could implement queries to Tribute Media or….).

Some series may not have any explicit linkage, for example “all programs named ‘QI’” and we don’t have a specific requirement for this (probably because we believed the Webapp would always be running and perform the necessary individual program recordings based on some user specified rules) – we should discuss whether we need to support this in the UA!

>>2. UA creates a bunch of correspondent scheduled recording requests. The actual number of created recording requests may depend on some intrinsic constraints of the UA. (For example, a TV series may run for a half year; whereas the UA may only allow to look up EPG within two weeks, or cannot schedule a recording request beyond one month from now.)
Are you saying here that the scheduled recording requests are only created when the call to addRecording(seriesId) is made? If so, the app would need to call this function every 7 days (or so) to kick the UA into updating the series recording!


>> Besides, are there any efficient ways to fetch the EPG based on the series ID under those broadcasting standards?
TV-Anytime has two mechanisms profiled by the OIPF (http://www.oipf.tv/web-spec/volume3.html#carriage-of-bcg-metadata)
Perhaps there are other standardized formats for EPG metadata and queries against them

Paul



From: Sean Lin [mailto:selin@mozilla.com]
Sent: Monday, August 03, 2015 6:18 AM
To: Paul Higgs
Cc: chris.needham@bbc.co.uk; public-tvapi@w3.org
Subject: Re: ACTION-33 and ACTION-35: API additions to remianing requirements

Hi,

I put my thoughts below.

On Thu, Jul 30, 2015 at 12:50 AM, Paul Higgs <paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>> wrote:
Hi Sean

I put my thoughts in here…

From: Sean Lin [mailto:selin@mozilla.com<mailto:selin@mozilla.com>]
Sent: Friday, July 17, 2015 3:41 AM
To: Paul Higgs; chris.needham@bbc.co.uk<mailto:chris.needham@bbc.co.uk>
Cc: public-tvapi@w3.org<mailto:public-tvapi@w3.org>
Subject: Re: ACTION-33 and ACTION-35: API additions to remianing requirements

Hi Paul & Chris,

I just have couple thoughts/questions about recording and time-shifting stated below inline. Please feel free to share your comments.

Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>

On Thu, Jun 18, 2015 at 12:23 AM, Paul Higgs <paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>> wrote:

4.       Access permissions should be considered. You would not want “just any” application being able to access (and modify) your lists of recording schedules or completed recordings.

•         recording.series

o   For this the recording scheduler needs to be configured with a EPG source. The easy way is for the implementation vendor to provide this information as a “browser data service”, alternatively we could permit the implementation to be provided with necessary URLs for a TV-Anytime implementation.
The problem is that so far there doesn't seem any field in EPG which could be reliably used for identifying a series of programs. TVProgram doesn't have relevant attributes, neither do some underlying broadcasting EIT examples I've found. (Please feel free to point out those which have such fields if you happen to have some.) So I'm afraid the implementation vendor may not have a common and reliable way to identify a TV series from EPG, before actually covering this requirement.

Besides, if there are some mechanisms that the web content can figure out / analyze the schedule of a TV series (for example, a page with the schedule of a specific series, or an app has specific protocols or pattern analysis to come out each series for some channels), would it be better to let this done by the web content by generating multiple recording requests?

PH> Series information could be carried in several ways

1.       In an extended_event_descriptor descriptor of an EIT-sched (DVB SI) – with some suitable definition for the values name (i.e. seriesID)

2.       In TV-Anytime metadata which is referenced via a TVA_id_descriptor within an EIT-sched

3.       Other methods for ATSC, ISDB…
It looks a series identifier might be available through different ways from couple broadcasting standards. So it could be exposed to the application by adding an extra nullable attribute like 'seriesId' to TVProgram. Then a possible way to support recording.series could be as follows:

1. The application calls addRecording with a specified series ID.
2. UA creates a bunch of correspondent scheduled recording requests. The actual number of created recording requests may depend on some intrinsic constraints of the UA. (For example, a TV series may run for a half year; whereas the UA may only allow to look up EPG within two weeks, or cannot schedule a recording request beyond one month from now.)

Besides, are there any efficient ways to fetch the EPG based on the series ID under those broadcasting standards? If not, the overhead could be inevitably high since UA may need to scan through all the programs in the same channel until some cut-off dates. Without knowing further information like the actual interval (daily, weekly, etc) between two episodes or the last day of the series, there doesn't seem a reliable way to reduce unnecessary scans. And what if an episode is played multiple times? What should we expect to handle potential duplicates?

Any thoughts?!