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

David Engel david at istwok.net
Mon Apr 13 18:35:10 UTC 2009


On Sun, Apr 12, 2009 at 01:48:49PM -0400, Shane wrote:
> On Sat, Apr 11, 2009 at 2:29 PM, Chris Pinkham <cpinkham at bc2va.org> wrote:
> > I think that's fine. ?After looking this and the orginal commit over, I
> > am wondering if the [15808] change would have been better to set
> > recorded.preserve = 1 which would eliminate the recording from being
> > included in the autoexpire maxepisodes count as well as this scheduler
> > query.
> >
> > This would also have the side-effect/benefit of keeping the original
> > around until the user did get a second copy of the recording and deleted
> > the original manually rather than having the recording get bumped off
> > because of the regular maxepisodes or autoexpire processes if it took
> > a while to get a new copy of the desired recording.
> 
> 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.

> I've attached a v3 patch to the ticket, v2 was bogus and I removed it.
> 
> v3 unconditionally sets preserve=1 in PlaybackBox::doAllowRerecord(),
> which would make "Forget Old" in mythweb inconsistent with "Forget Previous"
> in the frontend. :/   There are likely other ramifications I haven't
> thought of too.

I wouldn't be the first time mythfrontend and mythweb have differed.
They can be reconciled when the desired behavior is agreed upon.

> Now I'm thinking the special case of preserving an episode while trying to
> record another copy when maxepisodes is set is separate from the problem I
> set out to solve and should be dealt with in a separate patch.

I agree, but I don't feel real strongly about it.

David
-- 
David Engel
david at istwok.net


More information about the mythtv-dev mailing list