[mythtv-users] Myth autoexpiring brand new shows

Kevin Kuphal kkuphal at gmail.com
Tue Aug 26 13:37:05 UTC 2008


On Tue, Aug 26, 2008 at 4:50 AM, Yeechang Lee <ylee at pobox.com> wrote:

> Michael T. Dean <mtdean at thirdcontact.com> says:
> > > If you read my original post, I mention that there are hundreds of
> > > items on the auto-expire list that precede the recordings in
> > > question.  My auto expire is set to only consider age.  My issue
> > > is that they are not being expired in this order.
> >
> > They sure are.  You're forgetting about the fact that the "hundreds"
> > of items on the auto-expire list that precede the recordings in
> > question are on other filesystems (where deleting them would be a
> > waste, as it would mean hundreds of recordings must be deleted
> > before a deletion actually makes space available for the new
> > recording).
>
> The last sentence is a non sequitur.
>
> I'm firmly on Jonny B and Enigma's side. Michael, you and Kevin are
> both flat-out wrong on this issue. I'm very surprised that Kevin would
> miss this, as he is normally very on-target.


Thank you, but I was certainly starting this diagnosis from the most basic
position confirming that auto-expiration was set up properly, that items on
the list were expiring in order, etc.  From his further information in his
rather insulting and condescending response, it is clear that those items
are configured and the issue is with remote filesystems (which I don't use
so haven't experienced much).

>
>
> > But, in case I'm wrong about your wanting to figure it out for
> > yourself, I'll mention that one potential approach for "fixing" this
> > issue was provided in this thread and it all comes down to a
> > misconfiguration of your system.
>
> The above is, as far as I can tell, completely wrong. There is no
> evidence whatsoever that Enigma's storage group is misconfigured.
>
> I noticed the issue Enigma reported months ago, right after moving to
> 0.21 and creating a single storage group encompassing three
> recording directories over two backends: Recordings were being
> auto-deleted (sometimes almost immediately after beng recorded) even
> when dozens or hundreds of gigabytes of recordings elsewhere within
> the storage group should've been deleted first (based on their
> priorities or because they were in the Deleted recording group), as
> clearly indicated in the AutoExpire List. I never filed a ticket
> because, I figured, such an egregious issue would surely be fixed
> ASAP, right? After all, the wiki documentation
> (<URL:http://www.mythtv.org/wiki/index.php/Storage_Groups>) and the
> official documentation it quotes
> (<URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>
> both say that:
>
>    MythTV will balance concurrent recordings across the available
>    directories in a Storage Group in order to spread out the file I/O
>    load. MythTV will prefer filesystems that are local to the backend
>    over filesystems that are remote until the local filesystem has 2
>    concurrent recordings active or other equivalent I/O, then the
>    next recording will go to the remote filesystem. The balancing
>    method is based purely on I/O, Myth does not try to balance out
>    disk space unless a filesystem is too low on free disk space in
>    which case it will not be used except as a last resort.
>
> I read the above as saying that while MythTV normally chooses which
> directory to store a directory in based on a) local over remote and b)
> I/O balance, it would use c) free space as the governing criteria if
> the directories a) and b) suggested were out of room. As this thread
> demonstrates, other people interpreted this paragraph the exact same
> way.




More information about the mythtv-users mailing list