[mythtv] Proposed alternate behaviour for show delete

[Brad Templeton]

On Wed, Mar 09, 2005 at 06:48:56PM -0500, andrew burke wrote:
> > Undelete offers the ability to fix that, even if you didn't know
> > in advance, the other person didn't know they had to "register" as
> > a planned watcher etc.
> >
> > In general, I don't see any reason why you don't want undo anywhere
> > you can get it easily.
> 
> I think these arguments are good, but they are not related to the watcher
> list.
> 
> Reversible deletion is a separate issue.  It doesn't solve the 'should I
> delete this?' problem, which a watchers list does.  A watchers list
> doesn't solve the 'oh shit, I shouldn't have deleted that.' problem, which
> this would.

Actually, I believe it does deal with both problems to a degree.

A watcher's list is a useful feature, but complex.   You now have users
having to go to recordings and entering their names (ideally only once)
And when they have watched to go to a menu and pick off their name, and anybody
else in the room with them etc.   Certainly doable but a touch ugly and
possibly only minimally used.

Undo allows you to delete a program with impugnity.  If somebody else
wanted to watch it, they can get it back (within a given amount of time.)
Of course, don't delete it if you know they want to watch it but now
it's not a nasty sin.

A watch count has the nice advantage of requiring no user action.  It simply
counts the number of times the program has been watched.   It is displayed
in the delete/end-of-program menu.  In a typical household, most people
are going to know what shows are the favourite of whom, the human brain
being reasonably decent about this.   Not that it wouldn't be better to
be fully accurate, but the question is, would people really use it.

However, I have no problem with folks coding the watch lists and ability
to claim watching.  I just am advising that features which require no special
user behaviour get used a lot more and more effectively.


As for undo on delete, I believe I have a workable solution.  Namely, I
would consider modifying autoexpire so it has 2 space numbers.  One is
how much space to keep free (which it already has), and the other is how
much space to allocate for undo of delete.   If this 2nd number is set to zero,
no space is set for that, and delete will be near-hard delete.  (What I
would actually recommend is that delete is acted on on the 2nd pass of
autoexpire after the user requests delete, which is usually in about 20
minutes.  If you need to reclaim the space now-now-now, I would recommend
going to the actual delete screen which could offer hard delete etc.)

If the second number is set to a value, like 10gb, then up to 10gb of deleted
programs could be kept to allow undo.


Even if you allowed a large buffer for undo, I don't think it would interfere
with dvd-rips and cd-rips because they are not that fast, and autoexpire runs
moderately frequently in any event.   The only thing that would hit you up
would be raw file copies of very large piles of disk.  If that's in your plan,
you would be advised not to leave a large undo buffer, or to manually run
autoexpire.

This should address most of the concerns I have seen.  On the other hand no
point in us coding it if Isaac remains uninterested in having the function.
Mainly I suggested it because with the current autoexpire it was very easy
to code, literally just a few lines in a few places.  It's getting more
complex.  :-)