[mythtv] Re: Proposed alternate behaviour for show delete

[Daniel Manjarres]

On Sat, 12 Mar 2005 11:58:58 -0800, Brad Templeton
<brad+mydev at templetons.com> wrote:
> 
> I think this may be too roundabout a way to attain your real goal.
> 
> While myth has a variety of modes to give a show permanence (no autoexpire,
> no episode limit) due to bugs, you have lost shows you hoped were permanent
> which is very bad.

Those are actually not permanence modes, those are "don't delete by
mechanism x", but don't even try to prevent a delete by mechanism y
modes.

> What might be a lot simpler is for you to code a "permanence" flag (possibly
> simply setting autoexpire to -1), and, in all the relevant places, working
> to make those recordings permanent.

Sounds great, except autoexpire wasn't responsible for deleting those
shows (max_episodes was), so any solution to make autoexpire
smarter-than-a-human so that it magically can replace the manual
delete functionality, or any solution that involves using autoexpire
to implement undelete is useless to prevent disasters like mine. This
reminds me: I built a mythbox for my aunt, and one day EVERY SINGLE
RECORDING (400 GBs worth) got deleted (from database and filesystem),
when nobody was around. We never figured out what happened, thank god
she is acustomed to windows, and expect disaters, so she didn't flip
out.

Responding to your suggestion: What I like BEST from the ideas I sent
before is that mythtv could suggest shows to be deleted, but not do so
until the user confirms. Way back before autoexpire and max_episodes
the only way to delete was manually. When the auto_delete methods came
along we were supposed to just trust them, with no oversight. Well I
want oversight. Putting things into a delete_candidate pool would sav
lots of user time searching for individual recordings to delete, even
if they are not actually deleted right away. Advocates of "hard delete
cuz I said so" should favor this kind of feature for the non-manual
deletes, because then the computer is only doing what you say, not
going behind your back.

Anyway, to stay relevant, my point is this: if you are going to have
an undelete mechanism, it should work for every delete method, present
and future. So I think max_episodes should be an autodelete method,
parallel with autoexpire_oldest, as should all future delete methods.
That way a single undelete mechanism works for everything, and it
makes it possible to put in a panic stop in a single place and be sure
that it will prevent disasters in any autodelete code path. If this is
done autoexpire really needs a new name, since it will not be based on
just age anymore.

> Permanent recordings, in fact, should have a link to their .nuv file put
> in a second directory, so even rm can't get rid of them unless you know
> what you are doing.

I am using chattr +i myself. If I want to manually delete a recording
today I have to tell myth to delete it, wait for the backend to say
there was an error in deleting and print the actual file name, and
then chattr -i manually, and delete it again. Why? because myth has
proven itself to have occasional bugs or db problems that cause
disasters. It would be nice if this style of supervision was
integrated into myth.

> The proposed plans for undo on delete would not have helped you in a bug
> that was trying to purge your files.  Only a deliberate robustness could
> help there.

Which is exactly why I stuck my nose in here. There are 3 ways that
recordings can get deleted nowadays: User manually deletes them,
max_episodes deletes oldest, autoexpire frees up space on-demand. I
don't see any difference between them. I don't see any reason why you
would want to be able to undelete programs that were nixed by one
mechanism but not another. Currently I am behind on my watching of
"charmed" and the backend keeps deleting the oldest episodes that i
have not watched, even though there is 100GB of space laying around.
Sure I could manually extend the episode_limit temporarily, but with
100GBs of free space I shouldn't have to.

Here's my POV: there are only 2 reasons for ever deleting a recording,
by any method:

A) To free up space to be USED, not just for the sake of it being free.
B) To reduce clutter in the UI.

If a undelete method is written, it should not interfere with A or B,
and the best method will play nice with A and B. 18 months ago myth
didn't have autoexpire, or max_episodes, who knows what will be there
in 18 months? Program suggestions, that get deleted first? Stuff like
the sports_preemption_paranoia, or bad_reception that I described
before? Trying to map every possible delete scenario into a linear
range of autoexpire levels, judged by a single autoexpire_method is
crazy. What will happen when a new autodelete method comes along? I'll
tell you: somebody will re-adjust the coefficients that map things
into that simple linear range, and a bunch of recordings will be
deleted unexpectedly on user's machines. Wash, rinse, repeat every few
months.

I am asking for a behaviour from max_episodes that seems contrary to
the name, but the desired behaviour is really specified by A and B
above, guided by whatever auto_delete method is in use, not robotic
deterministic adherence to the name of the auto delete method, there
is no virtue in freeing up space that is not going to be used.

Anyway, I am not married to any of the details in my last few
messages, I am just interested in opening eyes to the fact that the
way deletes work is sub-optimal, and undeletes are not going to fix
all the problems. Adding things up My aunt and I have lost 600GBs
worth of recordings to non-manual deletes, and maybe 1 or 2 shows to
mistaken manual deletes . Thus I am more worried about max_episodes,
and other auto delete methods than I am about undelete, and wanted to
bring up a unifying theory of how to solve everything. A better theory
is welcome, if anybody has one.

I can't type much more, and I have not done a good job of explaining
how I see some of these ideas working. If anybody wants to talk things
out I can give you a call if you send me a number.

Thanks for putting up wth me,
Dan Manjarres