On Thu, 2006-01-12 at 11:18 -0500, Chris Pinkham wrote: > > Chris, I believe this is how it has always worked, overrecord is applied > > unconditionally to the recording. Then the overrecord time is overridden > > by StartRecording() when the scheduler wants to record something. This > > allows the overrecord to work in the presence of rescheduled or canceled > > follow-on recordings, without needing to update the end time. Updating > > the end time wasn't a feature when overrecord was first added... > > Overrecord (aka postroll) is supposed to always be optional and are applied > in the recorder. The per-recording start-early and end-late settings are > unconditional since they are applied on the scheduler's end.
Your right about the old implementation, I had forgotten about the 0.18 implementation. That code was changed a while ago, I believe to avoid some of the problems with clock drift on slave backends. The way it worked before my recent changes was that the over-record time was added to the recordEndTime initially, but if the scheduler wanted to record something it could override over-record in StartRecording(). This is still the case, except that this is blocked for a second or so, if you exit from LiveTV as the scheduled recording is about to start on that recorder until after we have checked if the current recording should be added to the scheduler's list and possibly added it. This is to avoid race conditions if you start watching LiveTV a few seconds before a scheduled recording is about to start, and so never get the 'recording about to start' dialog. Or, if you flag the recording you are watching as a regular recording after getting the 'recording about to start dialog' and then exit LiveTV, etc... -- Daniel _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
