[mythtv-users] live TV program overrun causes loss of recording

[David Engel]

On Mon, Jun 27, 2011 at 01:23:54PM -0400, Michael T. Dean wrote:
> On 06/27/2011 10:35 AM, blind_Pete wrote:
> > Something interesting just happened this evening.
> >
> > A TV program that I was interested in popped up on the guide, so I clicked on it for a single recording.  Earlier in the evening a live to TV program overran its schedule, by about 10 minutes, causing both the program after it and the program that I was interested in to be delayed as well.
> >
> > The first thing that I noticed was that MythTV had decided that the program was not listed an would not be recorded - despite it being clearly visible in the guide.  First the start time and program length changed, then later the end time changed and the program length returned to its original length.  I did not see the raw data for the guide.  (I'm not even sure how to get it.)  I don't know if the program length really changed or just the inferred length between adjacent start times changed.  A few program s have "gone missing" in the past, and this mechanism now seems highly suspicious to me.
> >
> > What is MythTV supposed to do in this situation?
> 
> Exactly what it did--you said to record a specific showing (which means 
> a show on a specific channel ID with a specific start and end time).
> 
> >    I can't really complain that it is not doing what it is supposed to do before I find out what it is supposed to do.  Presumably one of the following is designed and maybe documented behaviour.
> >
> > 1) The change in schedule is detected and tracked, recording the program when it is broadcast.
> >
> > 2) The change in schedule is ignored and the original time slot is recorded, possibly still recording the entire program if a big enough lead out time was configured.
> >
> > 3) The change is detected and found to be too confusing - allowing the now unused tuner to record a lower priority program on another channel.
> >
> > 4) The change is detected and found to be too confusing - and the tuner is left idle for the duration of the program.
> 
> 5) the change to the listings is detected and the show you asked it to 
> record no longer exists, so it doesn't/can't record that show.
> 
> > The data is coming from the free to air guide, but it is not an EIT problem because downloaded guides should be updated too.  It is just that the EIT data is updated more often and in this case at least reflected reality.
> >
> > I'm using a pre-compiled binary, mythtv-backend-0.24-20110303.1plf2010.2.x86_64.rpm
> 
> If you're using a listings source that changes start time frequently 
> (such as EIT), you should not use "timeslot" or "this episode" recording 
> rules--and, in general, even where people use "less-frequently-updated" 
> listings sources like XMLTV or Schedules Direct, you still shouldn't use 
> timeslot or "this episode" rules, except for very specific shows which 
> typically lack episode details (such as The Daily Show).
> 
> You should, instead, use "find one" rules--which allow you to record the 
> show, regardless of the start or end times.  Unfortunately, this means 
> you'll also have to watch for other showings that would match the "find 
> one" rule--which may mean, especially when setting up the rule a long 
> time before the airing, that you'll need a custom rule to get the right 
> episode.  (I'm pretty sure, though, that 0.25 will include an ability to 
> do a find one for a specific episode of a series.)
> 
> See, also, http://code.mythtv.org/trac/ticket/4879 --especially comments 
> 6 and 8 by gigem/David Engel (where he's currently doing the, "One idea 
> I have percolating is to add custom recording clauses that could be 
> enabled or disabled easily in the recording rule editor for regular 
> rules," part, which is what will allow find one for a specific episode).

What exactly are you envisioning here, Mike?  I hadn't given these use
cases much thought when adding the new filtering.  I imagine a couple
could kinda sorta work.

A filter like "(TIMEDIFF(program.starttime, RECTABLE.starttime) <
'00:15:00') OR (TIMEDIFF(RECTABLE.starttime, program.starttime) <
'00:15:00')" might work for a fuzzy single recording.  The UI would be
counterintuitive, though -- create an all or channel rule then enable
this filter.

A filter like "program.progamid = RECTABLE.programid" and a find-one
rule would work nicely to match an exact episode in most cases.  The
problem would be not being able to warn the user that doing this with
a generic programid wouldn't make senes.

David
-- 
David Engel
david at istwok.net