danielk at cuymedia
Sep 18, 2007, 12:25 PM
Views: 342
Permalink
|
|
Re: Ticket #3963: [PATCH] Use DTVRecorder::Reset() instead of derived class' Reset()
|
|
On Tue, 2007-09-18 at 12:11 -0400, Shane wrote:
> 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 |
> > ------------------------------------------------+---------------------------
>
> NVR/mpeg recorders:
>
> ResetForNewFile() ->
> reset some variables
> positionMap.clear()
> positionMapDelta.clear()
This is what we should be doing.
> 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.
I think the reason we don't do the reset this way in the DVB recorder
is because it doesn't have a functional Pause()/Unpause() like the NVR
does. But we I believe I fixed this in the multirec branch, so the
NVR ResetForNewFile() method would be safe with the DVB recorder in
the multirec branch.
-- Daniel
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
|
Re: Ticket #3963: [PATCH] Use DTVRecorder::Reset() instead of derived class' Reset()
