[mythtv] Ticket #11752: Recordings may end up in live tv group

[Michael T. Dean]

On 08/20/2013 05:37 PM, Joseph Fry wrote:
>>>> And, FWIW, there are very few reasons to ever define a Live TV Storage
>>>> Group
>>>> (and the only case where it makes sense is a less-than-ideal
>>>> system/storage
>>>> 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
>>>> believe
>>>> that having a dedicated partition for Live TV is better to prevent
>>>> expiring
>>>> 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
>>>> to
>>>> define the group by having a button specifically to create the group.
>>>> Users
>>>> see that and think, "I want to use Live TV," so they think they
>>>> should/must
>>>> 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
>>>> TV
>>>> 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 
system location.

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 
it's specified.

Mike