[mythtv-users] Myth autoexpiring brand new shows

Kevin Kuphal kkuphal at gmail.com
Tue Aug 26 21:20:54 UTC 2008


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

> Kevin Kuphal <kkuphal at gmail.com> says:
> > From his further information in his rather insulting and
> > condescending response,
>
> I'm sorry you took it that way, but put yourself in his shoes. He
> asked why programs are being autoexpired that shouldn't be (at least
> according to his, and my, and others' understanding) and you told him
> "Well, don't mark those programs to be expired." It's the equivalent
> of the old joke:
>
>   "Doctor, doctor, it hurts when I do this!"
>   "Well, then, don't do that."
>
> especially when his messages make it clear he understands the issue
> much better than that. You are normally on target (if curt, but the
> latter is OK with the former), but I am afraid you were the
> condescending one in this particular exchange.


With the lack of additional information, and knowing my own recording
habits, anything that I care enough about to complain loudly that it got
auto-expired, is not set to auto-expire.  A suggestion to fix this
particular issue it was not, but simply a suggestion on how the situation
could be avoid while a solution is determined.  Either way, his was an
unnecessary response to his request for help.  And I've learned from enough
troubleshooting in my day never to assume that someone understands the issue
better than what I've confirmed through some troubleshooting steps because
that more often than not just results in you missing the actual problem
because you overlooked something that was supposed to be "obvious".
Anyways...

>
> > From the OP, it appears without further information that he had a
> > single recording going at the time of the expiration.  In the case
> > of a single recording on what we can assume are all full partitions
> > (each one has about the same amount of free space indicating to me
> > that they are all at capacity), then Myth, based on the Wiki quote,
> > will use the local disk first for the next recording (remember,
> > Storage Groups only dictate where a recording will be stored, not
> > what will be expired).  As a result of local disk being chosen,
> > local programs are being expired.
>
> This is both illogical and nonsensical. It is illogical because the "a
> last resort" clause indicates (to me, Enigma, and others, at least)
> that free space indeed will be used as the final determinant *if
> necessary*, while you are saying--if I read you right--that this
> doesn't trigger unless "at least two concurrent recordings [are]
> active or other equivalent I/O."  If this is the case, the
> documentation is very very very much not clear.


It says that the free space will be used to break a tie.  There is no tie.
The drive with the lowest weight is always used first and in this case, that
is his local filesystem.  Done.  End of story.  The rest of the message,
while an interesting discussion, isn't for me to comment on as it is more of
a feature request to change how some people would like the defaults of
storage group weighting to be.

I personally would not want remote storage equally weighted with local
because of the potential I/O issues with network recordings, commflagging,
and the like.  The previously mentioned database setting laid out in the
wiki from the original coder does provide the advanced user this means of
making his/her system weigh local and remote identically so that a tie
situation does occur in which case free space will be the determining
factor.

Seems to me that Myth, once again, has set reasonable defaults for the
average system and provides a way for advanced users to tweak it to their
liking.

Kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20080826/a8b6c913/attachment-0001.htm 


More information about the mythtv-users mailing list