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

Joseph Fry joe at thefrys.com
Fri Aug 23 18:40:57 UTC 2013

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

More information about the mythtv-dev mailing list