[mythtv] Ticket #6438: maxEpisodes is not respected with back-to-back recordings

[Shane]

On Mon, Apr 13, 2009 at 10:25 PM, Chris Pinkham <cpinkham at bc2va.org> wrote:
> * On Mon Apr 13, 2009 at 01:35:10PM -0500, David Engel wrote:
>> On Sun, Apr 12, 2009 at 01:48:49PM -0400, Shane wrote:
>> > Not 100% sure but setting preserve=1 looks like it would protect the recording
>> > from being bumped off due to maxepisodes but still eligible for autoexpire?
>>
>> That's the way I read the code.
>
> Ditto.  I don't think that's an issue though.  Preserve was meant to be
> a way to get around maxepisodes.

Ok, good to know that is it's sole specific purpose.

...
> I think mythweb was broken and 15808 fixed it, so I don't think it's a
> big issue to change things now.  The 'Forget Old' button in MythWeb says
> that pressing it will allow the episode to record.  The only reason that
> is true now is because we set duplicate = 0 in
> ProgramInfo::ForgetHistory() and now honor that in the scheduler
> allowing a currently recorded program to be rerecorded.  Prior to 15808,
> that button would have not had any real effect until you deleted the
> original.

Ah OK, I was actually using my duplicate checking method to ignore
currently recorded episodes to allow re-record of an existing episode,
in when using mythweb's forget old for that. :)

>
> I think the best thing to do is for us to remove the duplicate <> 0
> check, update PlaybackBox::doAllowRerecord() to call
> pginfo->SetPreserveEpisode(true), and then we can add a way for MythWeb
> to set preserve = 0.  Having duplicate = 0 will allow the recording to
> rerecord, and having preserve = 0 will allow the original to not count
> against the maxepisodes.

Yep, that sounds good.

> Shane, have you tested that reverting the "duplicate <> 0" does fix your
> issue?  If so, you can revert that line and reference #3917 in the commit
> and then I'll reopen #3917 and commit the SetPreserveEpisode(true) fix
> now for mythfrontend and we can get MythWeb fixed in another patch.

Circumstances haven't been right to check the back-to-back recording with
maxepisodes set scenario but, the scheduler does un-schedule later
recordings when maxepisodes is reached, indicating it is counting the
in progress recording correctly. So I think it's good.

Shane