[mythtv] FIX "do not autoexpire" Flag made persistent

Chris Pinkham cpinkham at bc2va.org
Wed Oct 6 00:30:24 UTC 2004


> To me, there are really only two states: the system is allowed to
> delete this recording for whatever reason deemed necessary by the
> options I specified, or do not allow the system, under any
> circumstances, to remove a recording that I've decided to keep.

I agree with the two states, and that's what a undeltable/preserve
field would indicate.

> Because of this, I believe there should only be one flag. It doesn't
> matter if it's called "Auto Expire", "Allow Delete", or "Keep",
> "Preserve", "Archive", whatever (however, I don't like the double
> negative nature of "Undeletable". It is always better to say what
> something will do rather than what it won't not do).

That's why I keep putting that in quotes, I couldn't think of a
better one-word description suitable for a column name. :)

> Of course it would be technically possible to have options to say
> that a recording could be allowed to be deleted if there are too
> many episodes but not if the disk is full or delete if the disk
> is full but not if there are too many episodes but what would be
> the point of that? I'm sure someone could contrive an example of
> the exception that proves the rule but I have to believe that using
> multiple flags would be more prone to user error and confusion than
> doing anything useful. I don't want to consider multiple scenarios
> and multiple options when I decided to hang onto something. Either
> I've decided to keep it and I don't want any surprises or I'll
> allow the system to remove it whenever necessary. No other states
> matter to me.

I assume by this and the (unquoted) paragraphs below that you mean
turn the autoexpire field into "keep/preserve/whatever" :) and keep
the maxepisodes setting as-is.

So, all episodes that were not marked Preserve would be subjectable
to AutoExpiration.  I would think that would upset quite a few more
people (myself probably included once in a while).  I might not care
that a week-old Simpsons gets auto-expired, but Myth had better never
Auto-Expire an episode of CSI even if it is the oldest recording.  I
don't want to have to go through and mark every episode of CSI as
"Preserve" just so it won't be auto-expired before that 1st of
5 episodes of the Simpsons that I keep around.  And I don't want to
automatically mark CSI episodes as "Preserve" and have to turn off
Preserve in order to delete them manually.

> Of course it's fun to say this and it is a perfectly defensible
> argument. However, what I want is the best DVR system possible
> and while I can agree with your logic, Marcel's approach is really
> more like what I'd intuitively expect. 

I have some shows that are both set to auto-expire (because I don't
care if I have to delete them in order to record a new CSI) and
have a maxepisodes > 0 (because I don't want 20 episodes of the
Simpsons even though I like watching the show).  There are other
shows where I set a maxepisodes but don't want them to autoexpire
like my wife's home shows.  I limit her number of episodes, but
would definitely hear about it if Myth started automatically
deleting episodes of her show instead of those 5 Simpson episodes
when it ran out of space.  I think in this case, the proposed
logic/patch wouldn't count those 5 episodes of her show towards
the maxepisodes since they weren't set to autoexpire, so the
hard drive could fill up with Trading Spaces which airs 5 times
a day and 10 on weekends. :)

> I could go and increase the maxepisodes each time I chose to preserve
> an episode then decrease it if I later discard it. However, that seems
> like a pointless exercise. If I decide to preserve a show, it should
> no longer count as one of the limited disposable episodes. If the
> current wording doesn't fit this logic then the wording should be
> changed.

I don't mind the Preserved shows not counting against the
maxepisodes, but think that Preserve, Auto-Expire, and MaxEpisodes
are 3 distinct features and one shouldn't be overloaded or changed
to support another leaving us only 2 options.

-- 

Chris



More information about the mythtv-dev mailing list