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>
wrote:

> Hi Sean
>
>
>
> I put my thoughts in here…
>
>
>
> *From:* Sean Lin [mailto:selin@mozilla.com]
> *Sent:* Friday, July 17, 2015 3:41 AM
> *To:* Paul Higgs; chris.needham@bbc.co.uk
> *Cc:* 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
>
>
>
> On Thu, Jun 18, 2015 at 12:23 AM, Paul Higgs <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?!