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

Michael T. Dean mtdean at thirdcontact.com
Mon Jun 27 17:23:54 UTC 2011


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).

Mike


More information about the mythtv-users mailing list