[mythtv] Ticket #11752: Recordings may end up in live tv group
Michael T. Dean
mtdean at thirdcontact.com
Fri Aug 23 16:36:31 UTC 2013
On 08/20/2013 05:37 PM, Joseph Fry wrote:
>>>> And, FWIW, there are very few reasons to ever define a Live TV Storage
>>>> (and the only case where it makes sense is a less-than-ideal
>>>> configuration--so I don't know of any good reasons to define it). Not
>>>> defining a Live TV Storage Group allows MythTV to decide the most-ideal
>>>> location to store the new recording, according to the same Storage Group
>>>> Disk Scheduler selected for use with recordings. And, for those who
>>>> that having a dedicated partition for Live TV is better to prevent
>>>> something they want, dedicating space to only Live TV only reduced the
>>>> amount of space available for storing recordings.
>>>> Unfortunately, though, mythtv-setup makes users think it's a good thing
>>>> define the group by having a button specifically to create the group.
>>>> see that and think, "I want to use Live TV," so they think they
>>>> create the group.
>>>> We may want to consider doing less to encourage users to create a Live TV
>>>> Storage Group--such as removing the button in mythtv-setup "(Create Live
>>>> group)". Also, it makes sense to encourage distro packagers to stop
>>>> creating Live TV Storage Groups for users.
>>> I completely disagree. I use Live-TV storage groups religiously. If
>>> LiveTV is not in the same SG as my recordings, I can choose to backup
>>> just the recordings I care about, I can chose to RAID just my
>>> recordings, etc.
>>> Additionally, I created whats essentially a "WAF" storage group...
>>> containing shows that, if lost, might shorten my life expectancy. The
>>> folders in this SG are rsynced to a separate machine for live backup.
>>> Additionally I have a cron that notifies me of any recordings that are
>>> too small to be useful videos so that I can try and remedy the
>>> situation before the wife notices.
>>> Storage groups are a very handy tool...and being able to create more
>>> of them to suit your needs is what makes them so great.
>> I only said we need to stop encouraging users to create this one. For 99%
>> of users having a Live TV Storage Group defined does nothing useful--and
>> actually probably reduces functionality. I didn't say anything about
>> removing the ability to create a Live TV SG, I'm only trying to make it so
>> that users don't do it *unless they have good reason to*.
> Sorry, I did kinda go on a rant... but not at your proposal, just at
> your claim of the "only case where it makes sense is a less-than-ideal
> system/storage configuration..."
> And by the way, there is no reason you can't place your livetv SG in a
> directory next to your recordings storage group.
Remember, though, that a Storage Group is a *list* of directories.
> Mythtv recognizes
> that they are on the same media and balances them as you would want...
> so it's every bit as efficient as not using it.
So, assuming you have multiple directories in your Default Storage Group
(i.e. at least one per file system), you'd have to have multiple
directories in your Live TV Storage Group (at least one per file system)
that end up being a bunch of "right next to my Default Storage Group
directories", so you might as well cut out the middle man and just let
them go into the Default Storage Group directories. (Doing so also
means you won't have to remember to add new/modify Live TV Storage Group
directories /every/ time you change your Default Storage Group directory
list.) Basically, in that approach, The Live TV Storage Group directory
list is redundant information.
All this approach does is create a "shadow" directory that separates
Live TV recordings from non-Live-TV recordings, but requires 2x the
configuration to make it work. IMHO, the configuration isn't
worthwhile, especially since Live TV has an expiration ("Live TV max age
(days)"), which means you can (and will by default) force MythTV to
delete Live TV recordings after only one day. Therefore, they'll
disappear quite quickly.
And, if you're wanting to work with file system tools for backing up
files or whatever, you can easily do that using symlinks with additional
information (such as recording group) or even symlinks created for all
non-Live-TV recordings (i.e. without the --live argument), as created by
mythlink.pl . This also has the huge benefit that it allows you to back
up both the original file, by name, and a link to that file that
includes additional metadata that would be useful in placing the
recordings into Video Library in the event you ever lose your database.
I apologize if saying "less-than-ideal ... configuration" offended you,
but in general, I truly believe there are other/better ways to do
things--even if they aren't necessarily intuitive or obvious. The only
case where I see a Live TV Storage Group as being somewhat useful is if
a MythTV system is using central/network-mounted storage for all
recordings due to having only small hard drives on the backend
system(s), so the user decides to use a small portion of that small
local storage area for Live TV so as not to "waste bandwidth" by piping
Live TV over the network. However, IMHO, if the system is capable of
doing Z regular recordings at a time with that network-mounted storage,
it should be equally capable of doing X regular recordings + Y Live TV
recordings (where X + Y = Z) with that same storage (and, since there's
no such thing as "banking" the bandwidth, we're not so much "saving"
bandwidth as failing to use it.). This seems to be something people do
because of the innate desire for efficiency, even without truly
measuring the efficiency improvement or considering whether there's any
real benefit in what's being "saved" (i.e. bandwidth that's not
otherwise being used).
That said, using local storage for Live TV may make channel-change times
slightly faster, but I have a strong feeling the difference is small (or
even negligible) compared to the total channel-change time in Live TV,
on a properly-configured system (with attribute caching disabled on the
remount file system mount).
> But I agree that it's
> silly to put it on a separate partition... livetv is always expired
> before recordings anyway (at least on my system).
And, yes, that's true. Auto-Expiration always removes Deleted
recordings first, then Live TV recordings, then other recordings, as
specified by the Auto-Expire method (Oldest show first, Lowest priority
first, Weighted time/priority combination). Note, too, that if you set
Auto-Expire to expire "Watched before unwatched," any show marked as
Watched will be expired before un-Watched shows, regardless of the
Auto-Expire Priority of the 2 shows (though the group of Watched shows
are expired according to the Auto-Expire method and priority, and after
all Watched shows are gone, un-Watched shows are expired according to
the Auto-Expire method and priority). So, yeah, it generally does the
right thing (though if you enable "Watched before unwatched" without
understanding its consequences, you may not get the behavior you
desire). (And, short Live TV recordings (<2min) are deleted with
prejudice, basically immediately, to remove useless "channel-surf"
recordings from the Live TV chain so that you don't have to skip back
through 120 different Live TV recordings to re-watch that prior scene of
the show that occurred just before the commercial break that you spent
channel surfing. If any of these exist when the backend decides to
expire recordings, it will delete them first--even before Deleted
recordings, just in case that's enough space. So, we can basically
consider short Live TV recordings to not exist.)
The main wrinkle comes into play in the fact that Auto-Expiration occurs
/after/ the backend decides which file system to use for a new
recording, because Auto-Expiration only occurs on a file system when one
or more recordings are being written to that file system. That means
that your highest-priority-for-Auto-Expiration recording may not be
expired first because it's not on the file system to which the recording
is being written. But, then again, we have a plan for that and will
have an approach that alleviates this issue for users who want to ensure
shows are expired in an easily-determined order, regardless of file
But, wow, that's definitely the long way of saying, "Yes, Live TV is
expired before other recordings."
So, anyway, I'm not saying it's wrong to use a Live TV Storage
Group--just that it's almost always unnecessary configuration for users,
that only causes confusion. A Live TV Storage Group (and the confusion
it causes) was actually the reason for the invalid ticket
http://code.mythtv.org/trac/ticket/11748 , which is the one I meant to
reply to when starting this thread. If you want to use a Live TV
Storage Group and it makes things easier/better for you, feel free to do
so. I just want to stop encouraging new users (and distro packagers) to
create the Live TV Storage Group since it's more of a special-case
setting that's probably not needed on the vast majority of systems where
More information about the mythtv-dev