[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