[mythtv] RFC: Better handling of time changes for a Single Recording

[Matthias Dahl]

Hello all.

Lately I have missed several single recordings because the EPG data changed 
which led to a state change of the scheduled recording from "Will Record" to 
"Not Listed". In one case this happened as late as 10 minutes before the 
actual recording started.

IMHO this shouldn't happen. A DVR should not expect a user to check the 
scheduled recordings just before it is about to start if he/she really wants 
to make sure it gets recorded. Naturally there is always the possibility to 
use a manual record which is quite uncomfortable and lacks the EPG data that 
usually gets recorded along side with the show. One could also choose a 
different recording type but those have their own pitfalls and aren't really 
suited for a single recording at a specific date, time and channel.

So I would like to suggest an enhancement and put it up for comments. If we 
can agree on a single solution, I'd volunteer to _try_ to get it implemented 
which could be quite a challenge since the scheduler itself is quite a complex 
beast and not that well documented at all. But I like a good challenge. :-)

Solution 1:
-----------
If a program changes due to new EPG data or similar, we check if there is a 
scheduled recording for it and change the start and end times accordingly 
without touching any specified offset.

This would not go into the scheduler but the EPG handling code.

Solution 2:
-----------
If the scheduler cannot find a listing for a scheduled recording, it looks in 
a specified time range which we could either fix (+/- 30 minutes) or make it 
optional and tunable by the user with a default of +/- xx minutes for each 
recording specified. If the scheduler finds a recording within that time range 
we record it in recordmatch but do not change the scheduled recording itself 
thus avoiding the case that several subsequent EPG changes could lead to 
overstepping of the given time buffer.


Personally I think the nicest solution would be (1) but I don't know how 
feasible that would be. As far as flexibility goes, naturally (2) is better 
but would require changes to the db schema and scheduler changes itself. And 
judging from what I have seen of the scheduler code, it possibly won't be too 
pretty to get this in but I could be wrong there.

I'd really like to hear any comments on this. Especially if any one is already 
working on something similar or something that could be interfering. And also 
if this is considered a valid and good enhancement or if I should simply 
forget about it.

Thanks for taking the time,
matthias.