[mythtv-users] How to make "Record this program in This Timeslot every ..." more tolerant to late arrival EPG changes ?

[Michael T. Dean]

On 09/06/2011 08:26 AM, "Per J. Frøysa" wrote:
> Why not suggest to follow the specifications?
>
> /6.1.1 Accurate Recording
>
> Accurate Recording – the accuracy of recording is done by controlling 
> the start and stopping information based on EIT.
> Managing the exact time for recording a program is done by starting 
> and stop time driven by EIT p/f (present and following or sometimes 
> called now and next information) with reference to EIT schedule 
> information.
> The NorDig accurate recording of a program begins when the chosen 
> program is included the EIT present table and stops when the chosen 
> program is no longer in EIT present table (typically the EIT present 
> table is shift to include next program).
> The reference in the EIT p/f and EIT schedule for each program is DVB 
> Event Id and programming CRID. Booking (ie when the user programs the 
> PVR to make a recordings of a event/program) of a program via the EIT 
> schedule information is stored in the PVR receiver.
> When CID (Content Identifier Descriptor) for a program / event is 
> included in the EIT p / f, the NorDig PVR uses the CID as a reference 
> for the same event in the EIT schedule. A broadcast may split a 
> program into several parts in its broadcast and still signalize as 
> they are parts of the same program for the PVR, see chapter split 
> records./
>
> Looking into the EIT code, I can see that EIT P/F is decoded but I 
> cannot see that it is acted upon as a scheduling trigger?

FWIW, the problem here isn't that the listings data is providing an 
inaccurate/outdated start/end time, but that the EIT stream is reporting 
new/different start times after he has said to record a show at the old 
start/end time. Since EIT is updated continuously (and MythTV re-runs 
the scheduler every 5 minutes for EIT users), we are, in fact, acting on 
very current information--even if we are not using the now/next (or 
present/following) information.****

For example, the OP may be saying, "Record this program in /this/ time 
slot every day" (where "this time slot" means from the start time to the 
end time in the current listings--let's say from 8:00-8:30pm) . Then, 
the EIT data goes in and changes the start time to 8:01-8:31pm, which 
means the desired program is no longer airing from 8:00-8:30pm that day, 
so MythTV doesn't record anything, because no show matches the specified 
rule.

Therefore, the OP should not be using "this time slot" rules, but should 
be using "any time" rules.

If the OP says, "Record this program at any time on <this/any> channel," 
and it airs daily, MythTV will record it daily. If it airs multiple 
times per day, MythTV duplicate checking ( 
http://www.mythtv.org/wiki/Duplicate_matching ) will come into play to 
ensure each episode is recorded only once. Therefore, the only reason to 
use "this time slot" rules is when you have listings that provide 
garbage data that can't be used to determine whether the show is a 
duplicate or not--or you have a show where episode information isn't 
routinely provided (like The Daily Show - 
http://www.gossamer-threads.com/lists/mythtv/users/153872#153872 ).

Mike


**** And, using p/f would introduce a whole slew of problems--a cascade 
of changes could be required to the schedule due to times slipping--that 
would likely mean many users' backend systems couldn't handle the 
additional load of re-running the scheduler for each p/f change, even if 
limited to only following those around recording start/stop times.