As of [8553], overrecordseconds are imposed unconditionally

[bjm <bjm@…>]

To reproduce, schedule two shows back to back where the end time of the first is equal to the start time of the second. Verify that both recordings are asigned to the same card. During the transition, the first will continue to record until it reaches the endtime plus 'overrecordseconds'. However, it should have ignored this and started the second on it's starttime.

Here is one example with 24 overrecordseconds. "Eyewitness News" should have stopped at 12:30 so that "Dragon Tales" could begin. During the transition, the conflicts page showed the rscstatus of "Dragon Tales" as rsAborted.

2006-01-11 12:30:02.224 Canceled recording: Dragon Tales "The Balancing Act; A Small Victory": channel 1010 on cardid 1, sourceid 1
2006-01-11 12:30:24.135 TVRec(1): Changing from RecordingOnly to None
2006-01-11 12:30:24.155 Reschedule requested for id 0.
2006-01-11 12:30:24.194 Finished recording Eyewitness News at Noon: channel 1008
2006-01-11 12:30:24.581 Scheduled 7 items in 0.4 = 0.00 match + 0.43 place
2006-01-11 12:30:24.778 Finished recording Eyewitness News at Noon: channel 1008
2006-01-11 12:30:25.885 TVRec(1): Changing from None to RecordingOnly
2006-01-11 12:30:26.295 Started recording: Dragon Tales "The Balancing Act; A Small Victory": channel 1010 on cardid 1, sourceid 1

[danielk]

I will look at this tomorrow, I think this happening because kFlagCancelNextRecording isn't being cleared until the first recording finishes.

[cpinkham]

I think it's because the code in TVRec::GetRecordEndTime?() always applies the overRecordSecNrml or overRecordSecCat instead of optionally applying them.

[danielk]

(In [8577]) Fixes #1005.

Makes sure the kFlagCancelNextRecording flag is cleared when needed.

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

[danielk]

(In [8584]) References #1005.

[8577] did not fix the overrecord problem in the case where the recording used the 'Default' recording profile :/

The problem was some LiveTV code run without a check for the LiveTV state.