[mythtv-users] expiring expiring programs waaaaaay too soon

Brian J. Murrell brian at interlinx.bc.ca
Mon Dec 3 16:25:38 UTC 2012


On 12-12-03 09:36 AM, Michael T. Dean wrote:
> 
> Yes, expiry is never on a first-in-first-out (or even
> highest-priority-for-autoexpire-first-expired) basis--it's always
> highest priority /for the file system in use/.

Doh!  As much as I was willing to bet against it, that does seem to be
what's going on here.  I thought my storage pool (which is only 2 disks)
was much more balanced than that.

But indeed, it seems that I do have recordings on one disk at the top of
that disk's FIFO which I have not watched yet so things are pretty nasty
here.

> You are probably using
> the wrong Storage Group disk scheduler (which should be chosen based on
> how you use your disk):

I am using Combination because I really do want some I/O load balancing
going on.  I can be recording 4 or 5 (SD only) streams at once, all
being commflagged (well, probably not 5 in parallel -- I do think I have
a max of 2 or 3 or so) and some watching.

I guess I really need to try to balance the disks a bit more.  Should
just be a matter of moving half of the top of the expiry list for the
one disk to the other in exchange for stuff that shouldn't be expired.
i.e. so that both disks have roughly the same amount of deleted material
on them.

I wish MBE's --printexpire was more explicit about this situation.  :-(
 I guess I will have to script up what I just did to get the storage
group and file attached to each --printexpire line.  Would sure be
easier if MBE's --printexpire were more consistent with it's output of
title and subtitle.  Sometimes one is quote, sometimes the other is.
Sometimes neither is and sometimes both are.  Sometimes opening quotes
don't even have closing quotes.  ~sigh~

Heh.  I wish MBE did this re-balancing thing itself when it's otherwise
idle.  :-)

b.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 261 bytes
Desc: OpenPGP digital signature
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20121203/bd0c583e/attachment.sig>


More information about the mythtv-users mailing list