[mythtv] Ticket #3963: [PATCH] Use DTVRecorder::Reset() instead of derived class' Reset()

[Shane]

On 9/17/07, MythTV <mythtv at cvs.mythtv.org> wrote:
> #3963: [PATCH] Use DTVRecorder::Reset() instead of derived class' Reset()
> ------------------------------------------------+---------------------------
>  Reporter:  Shane Shrybman <gnome42 at gmail.com>  |        Owner:  danielk
>      Type:  defect                              |       Status:  new
>  Priority:  minor                               |    Milestone:  unknown
> Component:  mythtv                              |      Version:  head
>  Severity:  medium                              |   Resolution:
>   Mlocked:  0                                   |
> ------------------------------------------------+---------------------------
> Changes (by danielk):
>
>   * type:  patch => defect
>   * milestone:  0.21 => unknown
>
>
> Comment:
>
>  The patch is incorrect. We should be calling the overridden Reset().

Ok.

>  The
>  problem is really the Reset() in DVB Recorder which is at issue. Why is it
>  clearing the position map?

Hmm, the mpeg and NVR recorders also clear the position map from the
DB in their Reset() functions. I assume this is done to reset
everything back to a known initialized state at the same time. The
DTV/dvb recorder is inconsistent with respect to the NVR and mpeg
recorders, in that its ResetForNewFile() will also clear the the
position map from the DB and it doesn't for NVR/mpeg recorders.

NVR/mpeg recorders:

ResetForNewFile() ->
    reset some variables
    positionMap.clear()
    positionMapDelta.clear()

Reset() ->
    ResetForNewFile()
    reset some variables
    curRecording->ClearPositionMap(MARK_KEYFRAME)

DTV/dvb recorders:

ResetForNewFile() ->
    Reset()

Reset() ->
    DTVRecoder::Reset()
    reset some variables
    curRecording->ClearPositionMap(MARK_GOP_BYFRAME)

DTVRecoder::Reset() ->
    reset some variables
    positionMap.clear()
    positionMapDelta.clear()

So, is the better solution to try and make the Reset/ResetForNewFile()
more consistent across recorders? or My first patch for this problem
was to move the call to ResetForNewFile() in
RecorderBase::CheckForRingBufferSwitch(void) until after the
curRecording is changed to the new one so that we don't blow away the
position map for the last file.

Thanks for taking a look,

Shane