[mythtv-users] Mooting architecture for a DataDirect replacement

Peter Schachte schachte at csse.unimelb.edu.au
Wed Jun 27 06:27:34 UTC 2007


Jay R. Ashworth wrote:
> On Sun, Jun 24, 2007 at 01:11:17PM -0400, Rod Smith wrote:
>> On Sunday 24 June 2007 02:45, Peter Schachte wrote:

>> That does bring up a question that needs answering before such a
>> system could be formally designed: Just what form do updates take?
> 
> I was planning on an update message to carry one or more XML wrapped
> collections of scheduling and program data fields, which might be ADD,
> REMOVE, or REPLACE (which is actually a special case, and might be
> dropped -- except that I don't think you can; see below).

I think you can probably get away with just REPLACE.  If this is really an ADD,
then there won't be anything there already, so treat is as replacing emptiness.
 And why would you ever want to REMOVE an entry?  If you ever do, then replace
it with an entry that says "Dead Air."  Having only REPLACE makes the process
more robust, since it works correctly even if the previous ADD got lost.

Specifically, I don't think replacements want to be like diff entries that say
"look for something like THIS and replace it with THAT."  That's just extra
overhead, and unnecessary because each program has a date, time, and channel
that uniquely determines where it belongs.  The only tricky problem is handling
the situation where an update replaces part of the time span of an existing
program.

> 1) Most updates will come directly out of the automation software (or
> something which drives it) at the station/network), as they're put in.

This is a really crucial point.  This would be really good in terms of
reliability of the data, but do you have any reason to believe that you could
convince anyone to actually do this?  For one thing, this assumes that the
machines that do the scheduling are networked.  If I were managing a TV
network, I'd probably not want the scheduling machine networked, because I
wouldn't want someone to be able to hack in and air his diatribe on my network.
 The ultimate defacement:  airing a documentary like Outfoxed on Fox, or the
movie The Insider on CBS, right after 60 Minutes.  What fun!

> 2) Some updates may come from external sources (production companies
> may see fit to send out more comprehensive program descriptions at some
> point, we might talk TV Barn's Aaron Barnhart into sending out his talk
> show guest updates as overlays, individuals in specific communities may
> want to send out flash updates as they hear things, for those who
> choose to accept updates signed with *their* keys, etc.

That sort of update may be tricky to handle.  The production company might have
good description info to post but not know when it will be aired in each
market, particularly for a syndicated show.  They'd want to send out a message
like:  year 20, show 47 of Oprah has guests X, Y, and Z.  Then it's up to
someone else to work out which program to update.  There's also the lifetime
issue to think about:  what about when year 20, show 47 of Oprah is rerun some
months later?  You'd like to get the correct guest list, but you don't want to
keep around every posting made about every show ever aired to get it.

And even if you require every update to explicitly specify date, time and
channel, there's still the problem of out-of-order arrival.  You have to
introduce the idea of a "main" entry, and updates that are applied to it.  And
even then, if you have two or more sources that send updates to the same parts
of the same programs, then you've got a race condition.

I do think there's a strong argument for having a central site that collates
the incoming schedule information and distributes an authoritative schedule to
everyone.  The central site can have the resources to keep gigabytes of old
program descriptions around, and pluck them from the database when they're
being re-aired.  And the central site can date and sign the authoritative
schedule, so everyone knows they've got the correct latest schedule as of a
certain time.  In fact, if the central site has a policy about update
frequency, clients can know they have the absolute latest schedule available.



More information about the mythtv-users mailing list