Hi all,

Brad wrote:

I would roughly sort the expire pools as follows:

    a) Never-expire shows       = 0
    b) Unwatched shows          = 100
    c) Watched shows            = 200
    d) "suggestions" (possibly more than one pool)  = 300
    e) Shows manually cleared for removal   +1000 to earlier number

Within each pool, one sorts by date, however there are some alternate
internal sorts which might make sense. For example, explicit solo
recordings and non-rerun episodes might stand ahead of reruns and
find-all recordings. Ie. if you explicitly asked for something, protect
it more.

If there is a strict sort order (sort by 'autoexpire' first, then by date), then there is no difference between this and


    a) Never-expire shows       = 0
    b) Unwatched shows          = 1
    c) Watched shows            = 2
    d) "suggestions" (possibly more than one pool)  = 3
    e) Shows manually cleared for removal   = 4

Right?

The different numbers would only have an effect if they were being combined with something else...

Isaac wrote:

I think the various existing options work for most purposes (oldest first,
show limit, do/don't record new if there's a show limit, disabled for a
recording id, etc). Using the original recording priority would be a decent
extension, as would based on if it were watched or not.


I still don't see the point for an undelete function if autoexpire's
explicitly turned on.

I tend to agree with Isaac. But note that there are two parts to his response:


a) The undelete may not be so useful, given that you can...
b) Improve the autoexpire so that it gets things right.

I read this as just a call to get b) right.

I use the show limit function to actually limit the number of recordings (I only ever want one recording of the daily news). I also use it as a rough 'autoexpire' tuner. (We get 3 Simpsons episodes a day. I don't want a tide of Simpsons episodes causing all my other shows to auto-expire, so I set a show limit on it.)

I really like Isaac's idea of using the original show priority.

I wonder if a linear combination might work here. When deleting, shows are ordered by:

delete priority = weightA * time since recorded - weight2 * record priority + weight3 * watched_flag

The highest 'delete priority' show is deleted.

This way I can have watched shows being deleted first, then a trade off between shows of high record priority that I haven't watched in two weeks and lower record priority shows that are being recorded today.

I'm sure that the formula above could be tuned, but I thought I'd mention the concept.

Cheers,

Will        :-}

--
Dr William Uther                           National ICT Australia
Phone: +61 2 9385 6357               Computer Science and Engineering
Email: [EMAIL PROTECTED]          University of New South Wales
Web: http://www.cse.unsw.edu.au/~willu/     Sydney, Australia

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

Reply via email to