[mythtv] FIX "do not autoexpire" Flag made persistent
henri at qais.com
Tue Oct 5 04:42:12 UTC 2004
On 4 Oct 2004, "Chris Pinkham" <cpinkham at bc2va.org> wrote:
> > > I've had a few of the emails on this subject saved off so I could reply to
> > > them and haven't had a chance yet, but figured I should go ahead since
> > > someone is actually coding on this.
> > >
> > > I think that "Max Episodes" should mean "Max Episodes", not "Max Episodes
> > > except when blah."
> > seems that with your scheme you would run out of episodes
> > that you can record pretty quickly.
> If you hit the Max since old recordings aren't being deleted then you
> should bump the Max up.
> > and, it seems to me that this is already the case. if you
> > have 2 "record" entries for the same show visually you are
> > going to see more than the X episodes you selected in your
> > "Max Episodes" in one of the recording options.
> Actually since the Max Episodes is applied by title, if you have 2
> scheduled recordings for the same title, the one with the lowest Max Episodes
> is the one that _should_ matter. The Max Episodes code just checks titles, so
> it will only keep a total of X Max Episodes no matter how many
> scheduled recording entries were used to record the shows. There is a bug
> in the code though in that it's a shot in the dark right now as to which
> Max Episodes gets applied (since the code only orders by title and not
> by title ASC and maxepisodes DESC). The way it's expected to work is that
> if one scheduled recording says record daily at 2pm and says keep 3 episodes
> and another scheduled recording says record on Monday nights at 8pm and
> keep 2 episodes, the 2 takes precedence over the 3. If you set the
> Max to 2, it should only keep 2 Max, it shouldn't add together the 2 and
> the 3 since the Max Episodes is by title.
> Actually, I just committed a fix for the above bug. Now the code should
> correctly always use the lowest 'maxepisodes' for a given title no matter
> how many 'record' table scheduled recordings are scheduled for that title.
why is this correct and not the other way around? the
argument could be made that it should keep the highest
'maxepisodes' instead of the lowest.
> > replaytv takes care of this by moving the "saved" episode to
> > another group.
> > i think that when you say "keep this episode" it should move
> > the type of recording to "once"
> > so it would:
> > 1) create a new entry in record with a new recordid and change the type
> > 2) update the recorded entry to reflect the new recordid
> This is kinda kludgey and since Max Episodes works by title and not by
> recordid, it wouldn't work anyway.
that doesn't make sense to me. i really don't think that
settings in one record rule should modify what another
record rule does.
if the users has 2 record rules for a show that has the same
title, the assumption should be that they have a reason to be
doing so and want the rules for each recording to be followed.
this is very unclear and, in my opinion, counter-intuitive.
at the very least there should be some indication that the
max episodes is per title and can impact other record rules.
take law & order as an example:
how can i keep the new episode on NBC for more than a week
and still record the syndicated episodes on TNT (lets say i
want to keep 4 syndicated ones, in case i just want to have
something playing in teh background while i do something
else)? i don't mind that the TNT syndicated shows will get
booted from my list on an almost daily basis, but i don't
want to miss the new episode..
> If the undeletable flag was set and you wanted to mark certain episodes
> as undeletable, then you should bump your max episodes up.
in the above law&order scenario i would have to get to the
myth box the same night it was recorded in order to save the
new episode (since on some days TNT plays 4 law&order shows)
I see how there is a missing UI piece here that will give
the user feedback as to why/how a show was recorded and when
to expect it to go away. this is show in the replaytv
program listing and makes it quite clear to the end user
what to expect when it comes to the "shelf life" of the
More information about the mythtv-dev