If you are using one or more separate drives for video recordings storage, you will need to adjust the storage groups to reflect this fact (for later versions of MythTV, you will simply need to add the drives to one or more storage groups, since the pre-defined storage directory is no longer set up).
First, make sure the drives are mounted somewhere (e.g. /mnt/sdb1). If you do not set them up at install time or wish to add them later on, you can hack /etc/fstab to mount them. For example:
.
/dev/sdb1 /mnt/sdb1 xfs defaults 0 2
/dev/sdc1 /mnt/sdc1 xfs defaults 0 2
.
.
.
Or, if you wish to mount the drives by volume identifier, do something along these lines:
.
# /dev/sdb1
UUID=1113935f-a8b6-4f25-a57d-a6e73c69a136 /mnt/sdb1 xfs defaults 0 2
# /dev/sdc1
UUID=adf4297c-75d8-470e-9eda-802986c0d70d /mnt/sdc1 xfs defaults 0 2
.
.
.
After rebooting, For each of the mount points that mount a drive partition you should do the following:
sudo chown mythtv:mythtv /mnt/sdb1
sudo chmod g+ws /mnt/sdb1
This will allow MythTV to use the mounted drive partitions as storage space for recordings.
Optionally, if you wish to store several types of media on the new partitions, you should do this instead:
sudo mkdir /mnt/sdb1/music
sudo mkdir /mnt/sdb1/recordings
sudo mkdir /mnt/sdb1/videos
sudo chown mythtv:mythtv -R /mnt/sdb1
sudo chmod g+ws -R /mnt/sdb1
On the other hand, if you have a single, integrated drive that holds the OS, the /boot partition, the swap space and all of the recordings, you should define a new subdirectory in the root where MythTV can store recordings. For example:
sudo mkdir /MythTV
sudo chown mythtv:mythtv /MythTV
sudo chmod g+ws /MythTV
Or, once again, if you wish to store several types of media on the new partitions, you should do this instead:
sudo mkdir /MythTV
sudo mkdir /MythTV/music
sudo mkdir /MythTV/recordings
sudo mkdir /MythTV/videos
sudo chown mythtv:mythtv -R /MythTV
sudo chmod g+ws -R /MythTV
Now, you need to run mythtv-setup and add the additional storage to the storage groups so that MythTV can record to them. Probably the smartest way to go about it is to add the new paths to the Default storage group. That way, MythTV will use the new space by default. If you are using an older version of MythTV and want to prevent it from using any of the space on the system partition (or just the inaptly-named directory on the system partition), overwrite the predefined path, /var/lib/mythtv, with the first partition's mount point or the new MythTV subdirectory off the root. If you have more than one additional partition, add another path to the storage group.
Note that MythTV allows you to create new, named storage groups but then, if you do, you'll have to specify which storage group to use when you make a recording. The Default group, on the other hand, is chosen by default so it is probably the best place to attach your recordings storage.
If you want, you can add storage groups directly to the database. We prefer this approach if we're duplicating a current storage group. To figure out what to add, list the existing storage groups:
mysql -uroot -p mythconverg
select * from storagegroup;
At the very least, you should see default storage groups for each of your systems:
+----+-----------+----------+------------+
| id | groupname | hostname | dirname |
+----+-----------+----------+------------+
| 7 | Default | mainguy | /MythTV/ |
| 8 | Default | mainguy | /mnt/sdb1/ |
| 9 | Default | mainguy | /mnt/sdc1/ |
| 10 | Default | otherguy | /MythTV/ |
+----+-----------+----------+------------+
4 rows in set (0.00 sec)
Using the information from above, you could add a new Default storage group for otherguy:
mysql -uroot -p mythconverg
insert into storagegroup values(11,'Default','otherguy','/mnt/sdb1/');
In this case, we're adding a second volume that is mounted on /mnt/sdb1 on otherguy, to give us more space. Your storage groups should now look something like this:
+----+-----------+----------+------------+
| id | groupname | hostname | dirname |
+----+-----------+----------+------------+
| 7 | Default | bigguy | /MythTV/ |
| 8 | Default | bigguy | /mnt/sdb1/ |
| 9 | Default | bigguy | /mnt/sdc1/ |
| 10 | Default | otherguy | /MythTV/ |
| 11 | Default | otherguy | /mnt/sdb1/ |
+----+-----------+----------+------------+
5 rows in set (0.00 sec)
If you wish to weight the different partitions or directories in a storage group for purposes of giving preference to certain ones over the others (to, for example, include the system disk in a backend's storage group but only use it as a last resort when all of the other space in the storage group is used up), there is limited ability to do this via some undocumented settings, but there is no GUI to set them up.
Myth uses weights to determine which filesystem/directory to record to. The following default values are used:
SGweightPerRecording = 10
SGweightPerPlayback = 5
SGweightPerCommFlag = 5
SGweightPerTranscode = 5
SGweightLocalStarting = -1.99 * SGweightPerRecording
SGmaxRecOverlapMins = 3
The physical drive with the lowest weight is used first. In a tie, the physical drive with the highest amount of free disk space is used first.
Each Storage Group directory has its own weight, but Myth is smart enough to know if several directories are on the same shared filesystem. When a weight is applied to a directory that is in use, it is applied to all directories on that filesystem because Myth is trying to spread the load out across filesystems, not directories on the same filesystem.
The starting weight of all physical drives is 0. Local filesystems/directories are then offset by SGweightLocalStarting, so by default they begin at -19 (SGweightPerRecording defaults to 10). This implies that local drives are preferred over remote drives. A local drive has to have an effective weight of 20 before a remote drive will be used to store a new recording. If you do not have any playback going on, this would mean that you'd have to have 2 recordings going to a local drive before a remote drive would get used. If you have 2 local drives and 1 remote drive, you'd have to have 4 recordings going on locally before a remote drive would get used.
If you wish to alter the way Myth decides to use a drive (and, hence, the directory or directories on it), you can do so using the undocumented SGweightPerDir setting. In order to make Myth not use a filesystem/directory, we need to artificially inflate the starting weight for that directory. We can do so by inserting a specific SGweightPerDir setting in the database.
The database key used for the specific SGweightPerDir setting is:
SGweightPerDir:hostname:directory
The value for hostname is the actual hostname that mounts the directory. So if the directory is actually on server1 but is mounted via NFS on server2 (which is the server running mythbackend), we'd use server2 for hostname. The value for directory is the local path on hostname, so we'd use the mounted directory name (e.g. /mnt/video). For example:
SGweightPerDir:server2:/mnt/video
The value assigned to this setting will be applied as an offset to the initial weight for this directory. You can play it safe by setting the value to something large like 99 or 100 or even higher. To set a value of 99 for the directory shown in the example above, you would run the following SQL to insert this setting into the settings table:
insert settings
(value, data, hostname)
values("SGweightPerDir:server2:/mnt/video", 99, "server2");
This would pretty much guarantee that the directory would only get used as a directory of last resort, when all other directories filled up.
However, if you'd like to order the way the directories are used up but still have the local directory of last resort be used for recordings before any remote directories, you should pick a number that will result in a calculated weight that is greater than -19 but less than 0. If, for example you chose 15 (assuming that the directory is mounted on a local drive), when the Storage Groups scheduling code runs, /mnt/video will start out with a weight of 0, whereupon it will have an initial offset of -19 added to the 15, specified in the settings table via SGweightPerDir, to arrive at a weight of -4. Other, normal local directories start out at -19 while any remote directories start out at 0. So unless you have a two recordings, or four playbacks, or a recording and two playbacks going on each of your other local drives, the directory or last resort will never be used unless the locals fill up.
Finally, be aware that there is no way to delete a storage group from the GUI, once it is added, nor is they any way to delete a path from any storage group. You can change the name of an existing path but, if you set it to blank, the path will be set to "/" (when the crappy MythTV code adds a "/" to the end of the path). So, it is best to choose your storage groups carefully and add new path names carefully.
However, if you must delete a storage group or path from a storage group, you can connect to the MySQL database and delete it by hand from the storage groups table:
mysql -uroot -p mythconverg
select * from storagegroup;
Look through the listed storage groups and pick the one to delete:
mysql -uroot -p mythconverg
delete from storagegroup where groupname='MyGroup';
Alternately, you can delete the storage group based on the path to the directory where it is stored:
mysql -uroot -p mythconverg
delete from storagegroup where dirname='/my/store/path';