[mythtv] Proposed alternate behaviour for show delete

[Geoffrey Kruse]

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 <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>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2361 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20050309/d1aac974/smime.bin