Daniel Kristjansson wrote: > 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...
The first thing that struck me was to verify that that adding endoffset time would still be honored and that the second show became a conflict (single tuner) as the first show continued to record. However, I didn't get there. With 8577 in my test environment it still imposes the overrecordseconds. Could you verify what happens for you with the test case using current SVN, please? -- bjm 2006-01-12 11:25:02.727 Canceled recording: B (Manual Record) "Thu Jan 12 11:25:00 2006": channel 1010 on cardid 1, sourceid 1 2006-01-12 11:25:03.731 Reschedule requested for id 6867. 2006-01-12 11:25:03.853 Scheduled 8 items in 0.1 = 0.10 match + 0.03 place 2006-01-12 11:25:03.856 Canceled recording: B (Manual Record) "Thu Jan 12 11:25:00 2006": channel 1010 on cardid 1, sourceid 1 2006-01-12 11:25:24.946 TVRec(1): Changing from RecordingOnly to None 2006-01-12 11:25:24.949 Finished recording A (Manual Record) "Thu Jan 12 11:20:00 2006": channel 1008 2006-01-12 11:25:24.953 Reschedule requested for id 0. 2006-01-12 11:25:24.981 Scheduled 7 items in 0.0 = 0.00 match + 0.03 place 2006-01-12 11:25:25.309 Finished recording A (Manual Record) "Thu Jan 12 11:20:00 2006": channel 1008 2006-01-12 11:25:25.523 TVRec(1): Changing from None to RecordingOnly 2006-01-12 11:25:25.611 Started recording: B (Manual Record) "Thu Jan 12 11:25:00 2006": channel 1010 on cardid 1, sourceid 1 strange error flushing buffer ... 2006-01-12 11:27:48.421 Running HouseKeeping 2006-01-12 11:30:02.999 Canceled recording: C (Manual Record) "Thu Jan 12 11:30:00 2006": channel 1012 on cardid 1, sourceid 1 2006-01-12 11:30:24.200 TVRec(1): Changing from RecordingOnly to None 2006-01-12 11:30:24.203 Finished recording B (Manual Record) "Thu Jan 12 11:25:00 2006": channel 1010 2006-01-12 11:30:24.206 Reschedule requested for id 0. 2006-01-12 11:30:24.346 Scheduled 6 items in 0.1 = 0.00 match + 0.14 place 2006-01-12 11:30:24.521 Finished recording B (Manual Record) "Thu Jan 12 11:25:00 2006": channel 1010 2006-01-12 11:30:24.798 TVRec(1): Changing from None to RecordingOnly 2006-01-12 11:30:24.889 Started recording: C (Manual Record) "Thu Jan 12 11:30:00 2006": channel 1012 on cardid 1, sourceid 1 strange error flushing buffer ... _______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
