[mythtv-users] Myth autoexpiring brand new shows

Yeechang Lee ylee at pobox.com
Tue Aug 26 21:06:16 UTC 2008


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.

> 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).

Ah, the reason why things are the way they are becomes clear.

> 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.

Regardless of the proper reading, it is nonsensical because *it
defeats the whole stated purpose of storage groups*. Right off the bat
in the documentation, in 9.1
(<URL:http://www.mythtv.org/docs/mythtv-HOWTO-9.html#storagegroups>),
we are told that

    Storage Groups are lists of directories that are used to hold
    MythTV recording files giving you a flexible way to allow you to
    add capacity to your MythTV system without having to use exotic
    solutions such as LVM, filesystem expansion or RAID Online
    Capacity Expansion.

To any MythTV users sophisticated enough to know what LVM and RAID
are, the meaning is clear: A storage group lets a MythTV system use
multiple directories as if they were one. Period.

This unambiguous reading is supported wthin MythTV itself. Where,
within MythTV itself (minus plugins like MythVideo), is the concept of
drive directories ever used? I can't think of a single place. The
AutoExpire List does not distinguish between local and remote
recordings; on the contrary, its single, sorted-by-priorities list
reinforces the notion that all directories within a single storage
group are treated as equals for the sake of picking which recordings
to expire first. The Program Details screen explicitly omits
mentioning what directory that recording is in, only displaying the
truncated filename itself. Recording Options|Storage Options only
mentions storage groups, not directories within groups. Etc., etc.

Another sentence from the MythTV documentation, further down:

    Or, say that you originally installed MythTV to a 80GB hard drive,
    and that hard drive is now filling up. You could simply add a new
    drive to your system, mount it and update the Storage Group to add
    additional space.

The meaning is again unambiguous: Add a nice new empty drive to your
MythTV setup's storage group and MythTV will intelligently start using
it to store recordings in. We are now learning that the words
". . . if the drive is local, not remote" are missing. In any case, if
the documentation's only words

    The current load-balancing preferences (in order) are:

    * Local filesystems over remote
    * Less-busy (less weight) over more-busy (more weight)
    * More Free Space over Less Free Space

were truly followed it wouldn't be an issue because the system would
properly use free space as final determinant if the earlier criteria
aren't valid, but they're not and so it is.

> I think the suggestion of changing the local weighting is the best
> and documented solution.

I agree that this is the best solution for the time being. I disagree
that it is documented; the official documentation mentions some of the
weights but doesn't discuss how to change them and the key
SGweightLocalStarting weight is omitted anyway. More importantly, I
vigorously disagree that this state of affairs should remain the
out-of-the-box status quo.

In conclusion: Equality for all directories, regardless of location!

-- 
Frontend:		P4 3.0GHz, 1.5TB software RAID 5 array
Backend:		Quad-core Xeon 1.6GHz, 6.6TB sw RAID 6
Video inputs:		Four high-definition over FireWire/OTA
Accessories:		47" 1080p LCD, 5.1 digital, and MX-600


More information about the mythtv-users mailing list