One problem I see with just incrementing the auto expire is that some people use the "allow program to rerecord if auto expired" feature. Thus programs that they watched would never get marked as previously viewed.

Geoff

On Mar 9, 2005, at 8:23 AM, Mike Benoit wrote:

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 <[EMAIL PROTECTED]> 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
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev






_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
--
Mike Benoit <[EMAIL PROTECTED]>
_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
mythtv-dev mailing list
[email protected]
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Reply via email to