[mythtv-users] Confused about slave backend

Michael T. Dean mtdean at thirdcontact.com
Thu Feb 11 07:13:42 UTC 2010

On 02/10/2010 03:48 PM, Mark J. Small wrote:
> Hi everybody.  I'm in the process of setting up a second backend as a slave
> backend to complement the master.  The slave machine already hosts 2 nfs
> shares that store all of the recordings from the master.
> So on the master I have 2 storage directories set up in the default storage
> group, both of which are nfs drives hosted by the new slave.
> /mnt/store1
> /mnt/store2
> How should I set things up on the slave drive?  Do I add both of these folders
> (their local names are the same) to the default group on the slave?

Storage groups are defined on the master backend and the only thing you 
do on a remote backend is override the directory list defined on the 
master backend.  If you have the same list of directories on all hosts, 
you don't need to override the definition from the master backend with 
the same definition on the remote backend--the end result would be 
exactly what you started with.

As a matter of fact, because missing directories are ignored, the /only/ 
time you need to override a storage group directory list on a remote 
host is when the remote host has a directory in its filesystem that's in 
the master backend's directory list and you do /not/ want that directory 
used on the remote host.  So, if the master backend has a Default 
storage group with a directory list:


and on the remote backend you want to ensure that 
is *not* used for recordings, you would override the directory list 
defined by the master backend on the remote backend.

>    What
> would happen if I didn't do anything at all?

The remote backend would inherit the same directory list the master 
backend uses...  I.e. it would be configured just fine.

>    Would the recordings by sent to
> the master and back to the slave?

Storage groups do /not/ specify hosts for recording.  It is impossible 
to create a storage group that exists only on one host (that is, if you 
create storage groups properly, using the UI).  As mentioned, any 
storage group defined on the master backend is inherited by remote 
hosts, so exists on all hosts.  And, if you run mythtv-setup on a remote 
host, you'll find that it's impossible to add new storage groups.  The 
closest you can do is define an override for the "defined in code" 
storage groups (LiveTV, DB Backups, and MythVideo's storage groups).

Therefore, since all storage groups exist on all hosts, they have 
absolutely no effect on where shows are recorded.  Only the card input 
selection (performed by the scheduler) determines where the shows are 
recorded (which is why my inputs are added such that 1 and 4 are on the 
master backend and 2 and 3 are on the remote backend--doing so helps to 
balance disk usage across my backends even though I don't use any 
network file systems).

Even if you define a storage group and ensure that none of the 
directories listed within that group exist on one of your hosts, that 
group still exists--it just ends up with the directory list from the 
Default storage group.

The /only/ issue with configuring your system "properly" (with storage 
groups defined on the master backend and /not/ doing any overrides on 
remote backends) is that the backend status page won't show the proper 
hostname associated with the file system.  I plan to fix that sometime, 
but it hasn't been high priority.

The benefit of configuring it properly is that you have only a single 
location from which to manage all of your storage groups and if you need 
to change the layout of your file systems, you can do so on a single 
host and the changes will apply to all hosts.  If you define the groups 
on the master backend and then override the definitions (with identical 
definitions) on all remote hosts, every time you change your file system 
layout, you'll need to change definitions on all hosts--and if you 
forget to change some or all, you'll have hard-to-diagnose "strange" 
things happening with your recordings and file system usage.

The whole point of Storage Groups is to provide an abstraction of 
physical file system layout--instead using a simple, human-readable 
name, which is then linked to physical locations on the file system at 


More information about the mythtv-users mailing list