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

[Chris Pinkham]

> On Wed, Oct 06, 2004 at 07:06:24PM -0400, Chris Pinkham wrote:
> > > What if we just inverted the flag so that it indicates "Keep this until 
> > > I delete it".  Then it's just a matter of a dbCheck update and some UI 
> > > text for the existing installations.
> > 
> > If all people want "Preserve" to mean is that the system won't delete a
> > recording, but that the user can, then this might work.  If "Preserve"
> > means that the user (or their kids) can't accidentally delete a recording,
> > then this won't.
> > 
> > I could go for either definition since I don't have any kids right now. :)
> 
> Either approach requires finding *everything* that deletes recordings
> and making it respect the flag, as far as I can see.

That's kinda simple since there's not that many.

I should have worded my reply a little different.  I can go with either
definition as long as it preserves existing functionality. :)

> I don't much care what the polarity of the flag is, but IMO, it needs
> to *mean* "nothing at all can delete this", and if a user wants to
> delete something, they should have to manually unflag it.

This is my point about the reasoning behind Undeletable/Preserve.  I make
use of all the current 4 scenarios:

1) AutoExpire ON, MaxEpisodes OFF (single-records that I might not watch
	so I don't care if they autoexpire)
2) AutoExpire ON, MaxEpisodes ON (ie, set to non-zero) (series that I like
	to watch but want to limit the # of recordings and let them expire if
	need be to record a better show) :)
3) AutoExpire OFF, MaxEpisodes OFF (series I really like so they should
	never be autoexpired and I don't care if they fill up the hard drive)
4) AutoExpire OFF, MaxEpisodes ON (series that I (or my wife) like enough
	to not let them autoexpire but also don't want them filling up the
	drive)

If "autoexpire" is changed to "preserve" then there's 2 ways that
could be done:

A) "preserve" means the recording is only deletable manually by the
	user.
B) "preserve" means the recording is not deletable at all and the
	flag must be turned OFF in order to delete the show manually.

I think there are people that would prefer 'A' and people that
would prefer 'B'.  Maybe this is really a 3-state combobox and
not a new setting.

AutoExpire could be renamed "preserve" and would have the following
3 values (even if the DEL_ names aren't pretty right now):

DEL_PROTECTED   = 0x0000 = "Do Not Allow recording to be deleted"
DEL_MANUAL      = 0x0001 = "Allow recording to be deleted manually by user"
DEL_UNPROTECTED = 0x0003 = "Allow recording to be deleted manually by user
                            or by Myth if it deems necessary"

There would also be another bitmask of DEL_AUTODEL = 0x0002 for ease of
programming.

I think this would preserve existing functionality and add the
ability to Preserve a recording both from automatic and manual
deletion.  I skipped 0x0002 because potentially that could be used
as a DEL_AUTO flag to indicate the recording could only be deleted
automatically if that odd case ever came up.  So this value would
be treated as a bitmask.

Along with the "Max Episodes" changing to "Max Deletable Episodes"
(or whatever the terminology change is) I think people would get the
functionality they desire.  "maxnewest" could potentially go away in
favor of setting "preserve" to DEL_UNPROTECTED vs DEL_MANUAL.  If a
recording had maxepisodes == 5 but was DEL_MANUAL or DEL_PROTECTED,
then no new recordings would occur once the max was reached.  If
the recording was DEL_UNPROTECTED, then myth would start recording
the 6th episode and the maxepisodes code would remove the oldest.
The autoexpire field on a scheduled recording would also be renamed/changed
to support these same values, so a scheduled recording could be setup
automatically to be DEL_MANUAL or DEL_PROTECTED.  This would replace
the maxnewest functionality.

The MaxEpisodes and AutoExpire code would skip the recording if
the preserve field bitmask did not have the DEL_AUTODEL bit set.

> And all new code that might delete recordings should have to respect it.

That's the reasoning behing putting the check in the backend's delete
routine as well so it would have to be honored, it's just nicer if the
"frontend" app handles it rather than getting an error back from the
backend when trying to delete.

How does the above idea concerning a 3-way setting vs On/Off set
with people?  Would this be clear enough to users?  You'd have only
2 settings, "MaxEpisodes" and "Preserve Recordings".

-- 

Chris