[mythtv] Proposed alternate behaviour for show delete

[Mike Benoit]

Any "watched" counter would be helpful. I've been waiting for MythTV to
get this for a while. 

I'm sure it would be pretty simple to increment such a counter after a
front-end has viewed 80% or more of the recording (or some reasonable
other criteria). Then when auto-expire time comes around, the
"auto-expire score" could be increased by the watch counter value, so
the shows watched the most would be more likely to be deleted first.

This would especially useful in the cases where you might have 5
episodes of one show, and they get watched "out of order". If the 3rd
episode gets watched 4 times, the 1st episode (oldest) is going be
deleted first, even though no one has ever watched it.

Having actual users mark shows as watched would probably be the ultimate
goal, but something like this I think would work wonders in the mean
time.

On Wed, 2005-03-09 at 18:57 +1000, David Whyte wrote:
> This requires knowledge of users.  
> 
> I like Brads idea, and I also like the idea you have but it is not a
> simple addition.
> 
> Dave
> 
> 
> On Wed, 9 Mar 2005 00:14:08 -0800, Geoffrey Kruse <gkruse at gmail.com> wrote:
> > Along the same lines, a "mark as watched" item could be useful for
> > situations where there is more than one user on the machine.  Say user
> > A has watched the recording but user B also wants to watch it.  It
> > would be useful if myth could remember who has watched what.  This
> > could be achieved by letting each person mark a recording as watched
> > and not deleting it until both users have done so.
> > 
> > Geoff
> > 
> > On Mar 8, 2005, at 10:22 PM, Brad Templeton wrote:
> > 
> > >
> > > This proposed alternate behaviour requires minor changes to a number of
> > > different segments, so I thought I would propose it here before
> > > attempting
> > > any coding on it.
> > >
> > > As you may not know, autoexpire is not just a boolean, it is a number.
> > > Programs with a higher autoexpire number expire before anything with a
> > > lower number.  Programs with 0 never autoexpire.   AFAIK, tvwish is
> > > the only program making use of this, to allow imported suggestions to
> > > effectively only take spare space (a value of 2 is sufficient as the
> > > default
> > > is 1.)
> > >
> > > Anyway, the proposed change is as follows:
> > >
> > > If autoexpire is enabled:
> > >
> > >     Have Delete, instead of deleting the program, simply add 1000 or
> > > similar
> > >     large number to autoexpire.
> > >
> > >     Modify the query for current recordings to not present any entry
> > > with
> > >     autoexpire >= 1000.  Clients including mythweb will not see them.
> > >     Alternately train clients to ignore them or show them optionally.
> > >     (harder)
> > >
> > >     Modify the "deleted programs" to show them, but to put a special
> > >     highlight on these entries, and possibly display them at the end of
> > >     the list.   Also, it should now show 3 disk space totals -- space
> > > used
> > >     by visible programs, space "Ready for deletion" and actual free
> > > disk
> > >     space from DF.    Total "free" (actual plus ready for deletion)
> > > might
> > >     be shown.   Mythweb would need to be modified to show this.
> > >     (This might, unfortunately need a protocol modification to show all
> > >     the different numbers)
> > >
> > >     In deleted programs, Delete on an "already deleted" show really
> > > deletes
> > >     it, no undo possible.
> > >
> > >     In deleted programs, undelete is offered for already deleted
> > > programs.
> > >
> > >     Above two items also available in mythweb.
> > >
> > > Alternate suggestion (with more UI)
> > >     Put both "Delete" and "Recycle" on the delete menu, with Recycle
> > > grayed
> > >     out if autoexpire is not enabled.   Frankly I think this is
> > > needless
> > >     complication, and besides, it means a frontend change while
> > > changing
> > >     the meaning of delete is just a backend change.
> > >
> > >
> > > Result: Delete can be undone, at least until the space is actually
> > > needed.
> > >
> > > Thoughts?
> > > _______________________________________________
> > > mythtv-dev mailing list
> > > mythtv-dev at mythtv.org
> > > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> > 
> > 
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev at mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> > 
> > 
> > 
> > 
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-- 
Mike Benoit <ipso at snappymail.ca>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050309/aef8e72b/attachment.pgp