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

[Joseph Fry]

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

I don't necessarily agree with everything you said, but I do agree
that it's unnecessary in many cases and would help to eliminate
confusion for new users to have it removed by default (so long as it
remains configurable).