[mythtv-users] How do I -COMPLETELY- disable the expirer?

[f-myth-users at media.mit.edu]

    > Date: Thu, 20 Apr 2006 08:26:14 -0500
    > From: Kevin Kuphal <kuphal at dls.net>

    > f-myth-users at media.mit.edu wrote:
    > > I just discovered (in 18) that I don't have any recordings older than
    > > March 25.

[Long explanation of how Myth apparently thought my filesystem was
zero-size for an instant omitted.]

    Don't set any recordings to expire.  Myth only expires what you allow it 
    to expire so if you want to continue to manage things manually, just 
    don't allow anything to expire and hope you never forget to check the space.

The problem here is that Myth is apparently completely willing to
believe absurd values.  Perhaps this is better in 19.  But for the
instant my filesystem was reporting a total size (I believe!) of
zero bytes (certainly MythWeb was saying -something- like that,
if "B" is a number), the expirer tried to kill every recording
on the box.

The only reason it didn't is because the vast majority of them were
scheduled with MythWeb, which defaults autoexpire OFF.  The recordings
that were killed were ones I scheduled when the box was brand new, and
I was using the frontend UI instead---that defaults expire ON.

(I'd argue that they shouldn't have conflicting defaults, but given
the behavior I saw, I'm glad they did, and that MythWeb's was safer!)

I verified this by looking at old copies (pre-bananas-behavior) of my
DB, and it's clear the recordings that vanished all had autoexpire
enabled.

Having autoexpire bash things without checking for sensibility seems
like having a loaded gun aimed at my head.  Having to ensure that all
recording profiles have autoexpire turned off to avoid this seems
suboptimal.  And I've seen other reports of NFS glitches that might
have done this to others.  (My backend shares its recordings directory
with a FE/SBE via NFS, though -presumably- the expirer only runs on
the -master- BE and thus sees the filesystem directly, not through
NFS---is this true, or might -any- BE, even a slave, expire stuff?
That seems -really- dangerous!)

I'd argue that filesystem size = 0 means "abort expiry and complain",
not "assume (or believe a report of) freespace = 0 and expire".  I'd
-also- argue that the expirer should confirm that the freespace is
indeed increasing after each individual program is expired, and abort
and complain if it's not---it runs so fast that I'd expect freespace
to increase much faster than anything else could be filling it up.  It
should not just delete as much as possible without sanity-checking the
results coming back after each action.  At least that way, if it was
really confused, it would delete -one- thing and bomb (until the
backend is restarted? something like that), rather than potentially
erasing the entire recording directory.

What would happen if I set my expiry threshold, not to 0 bytes, but to
a negative number?  (I don't trust zero because I haven't rigorously
checked the code of the expirer in all versions wrt < vs <= sorts of
comparisons.)  I haven't tried doing so (I assume the UI would try to
prevent me, meaning I'd have to set it directly in the DB).  Is a
negative freespace value equivalent to killing the expiry process
completely?  (Yeah, I know, "unsupported configuration".  The
question's still valid.)