[mythtv] [mythtv-commits] mythtv commit: r8577 by danielk

Bruce Markey bjm at lvcm.com
Thu Jan 12 19:41:29 UTC 2006


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


More information about the mythtv-dev mailing list