User Manual:MythTV structure
This page is up-to-date to MythTV version 0.21, the current release is 29.0
For a description of how Storage Groups apply to MythVideo in .22 see MythVideo
The previous chapter explained the "general" backend settings. Settings pertaining to mythbackend which (when properly configured) will allow a MythTV system to watch live and record television will be covered here:
- General — General Backend settings (Discussed in the previous chapter)
- Capture Cards — Add and configure capture devices here
- Video Sources — create guide data.
- Input connections — Assign EPG data sources to capture cards / video inputs here.
- Channel Editor — scan and configure channels here
- Storage Directories — Configure (but not create) directories MythTV uses as storage for the likes of recordings.
- System Events — Configure scripts to be run by event triggers.
This chapter explains all the basics but for your convenience we have included specific chapters in this manual for each type of capture device (See the index of this manual).
For flexibility, MythTV uses a modular approach to internal architecture. This - unfortunately? - also means that the MythTV administrator - You! - has to get familiar with this architecture to make the most of his/her system, especially if it contains more than one single capture card!
The first element in any mythtv system is the capture card(s): these can be actual TV cards (analog or digital), 'Virtual' IPTV cards such as the FreeBox recorder, or simply video capture cards connected to an external set-top box. All these cards provide a video feed to the system, and receive orders from the system to change their active channel(s), move a satellite dish, simulate a remote key press, you name it. One of the strengths of MythTV is that you can install several capture cards on your system and merge content from many different origins on the same box: DVB, Analog TV, IPTV, etc, and to allow recording a program (or several if you install more cards) while watching another.
Video Sources define the methods for retrieving Electronic Program Guide data (EPG) into the system. These sources can be created using mythtv-setup and then associated with specific Capture Cards in the Input Connections screen.
MythTV can extract EPG from capture cards that support this, but since broadcast EPG data is usually fairly limited in terms of timespan and content, it can also download data from the Internet using ancillary software such as XmlTV. In a typical MythTV setup, you will create one separate source per type of capture card (analog, DVB, IPTV) that is installed on your system. For each source, you will select how the program guide data is fetched, and for what channels this data should be fetched. This can be slightly confusing for many users, as there are many different program grabbers with different capabilities and slightly different behaviors depending on what area in the world you live in. (there is a good chance MythTV will actually request you to get back to the terminal window to manually configure the mapping of Program Guide data and actual channels - more on this later -.)
- Section 9.1 of the manual describes the setup process for video sources. North American users can choose SchedulesDirect to supply the schedule information while those outside North America should use XMLTV. Transmitted guide data (EIT) can also be used as a source or a supplement to the other sources if it is available. This information is stored in the database as entries in the videosource table.
Once you have defined your capture card(s) and Source(s), you will move on to "Inputs".
Inputs are where you link one or several capture cards (providing video streams) to a source of program guide data (providing information about the video streams in question).
This allows you to define channels that each capture card can record.
Beware, though: you should not link several different types of capture cards with the same source. e.g, a video source for a DVB USB dongle will have one set of channels. That same set of channels will not be used for IPTV streaming from your ISP or PCI Analog TV capture card.
One situation where you will link several capture cards with the same source is when those capture cards are all the same type (eg. all DVB and they get the same input feed, or all Analog, etc).
As part of creating the Input, you will trigger a channel scan, which should, if all goes well, automatically discover all the available TV channels that are available on your capture card, and also match the channels to Electronic Program Guide data provided by the source. Nevertheless, depending on the program guide grabber that you use, your mileage may vary quite a lot since you will often end up with a slight or big mismatch between TV channel names / CallSign / Number and EPG data identifiers that are stored in the database... No worries, though, it all can be easily corrected in the...
This last setup screen shows you the result of all the previous steps: a complete list of all the channels that were detected for all the capture cards on your system, along with the name of the EPG source linked to each channel. In the edit dialog for each channel, you will be able to specify if EPG data for the channel should be gathered over the air, or should come from a specific XMLTV program ID. This is where you will see whether your XMLTV grabber correctly identified each channel or not: if not, you will end up with bogus channels with "???" as channel number. If so, simply write down the XMLTV ID for the bogus channel and put this ID in the real channel. You can then delete the bogus channel.
One thing to watch for, in case several of your capture cards receive similar channels - for example, analog and DVB cards that have some TV channels in common - : you cannot use the XMLTV ID of Source 1 as the XMLTV ID for a channel that belongs to Source 2, even if the channels are the same. This sometimes means that, unfortunately, you will end up duplicating xmltv grabbing for the same channels on each source: if you are reluctant to do this, you can move on to more advanced settings and grab the guide data once, and feed it to several sources, but this is beyond the scope of this introduction.
The last element, and arguably the most important, is the channel: channels in MythTV are identified by quite a few elements: "Channel Name", "Channel Number", "Channel Callsign", not to mention extra info such as channel frequency info, etc. Depending on the type of capture card that you use, some elements are used, and some are not: typically, for DVB channels you will not setup anything in the frequency fields - I am not quite sure whether the channel Callsign, Name or Number or a combination are used to tune the channel with DBV tuners - .
A page or section should probably be written to describe all this more in detail, but this again is beyond the scope of this intro!
Storage Groups are lists of directories that are used to hold MythTV recording files. By default, there is only one Storage Group, called "Default".
Additional Storage Groups can be created to store specific recordings in their own directories. Storage Groups are edited via the 'Storage Directories' section of mythtv-setup. It may be desirable to add multiple directories (which are mounted on different hard drives) to a Storage Group in order to spread out filesystem I/O onto multiple filesystems.
Multiple Storage Groups can also be created to group recordings together; recording schedules now have an option to specify which Storage Group to use.
MythTV will balance concurrent recordings across the available directories in a Storage Group in order to spread out the file I/O load. MythTV will prefer filesystems that are local to the backend over filesystems that are remote until the local filesystem has 2 concurrent recordings active or other equivalent I/O, then the next recording will go to the remote filesystem. The balancing method is based purely on I/O, Myth does not try to balance out disk space unless a filesystem is too low on free disk space in which case it will not be used except as a last resort.
Storage Groups are global, but can be overridden on a slave backend by creating a local Storage Group by running mythtv-setup on the slave. If a problem occurs and the slave backend is unable to use the desired Storage Group, it will fail back and try the directories defined in the master's Storage Group.
A special 'LiveTV' Storage Group may also be defined. If a LiveTV Storage Group directory exists, it will be used instead of putting LiveTV recordings in the Default Storage Group, allowing LiveTV recordings to be stored on their own filesystem. This is similar to the old MythTV method which used a RingBuffer for LiveTV.
To remove a storage group from the list, highlight it and press the 'D' key. This does not "delete" the files, it only removes the directory as a storage location. If the storage group you wish to remove is not empty (which is likely the case as MythTV balances the load), you can move these files from one storage group to another with a regular filesystem move. The next time MythTV tries to access these files, it will automatically search all available storage groups to locate them.
Usage information for all Storage Group directories is visible on the mythfrontend status screen as well as the mythbackend status webpage. MythTV is smart enough to determine which directories are on shared filesystems so it should not count free or used space multiple times if more than one directory is on the same filesystem.
- Added by Darryl Ross on 2007-03-06: Some details about the algorithm and weighting Myth uses to spread out the recordings across disks in the storage groups is on the Storage Groups Weighting page. Thanks to Chris Pinkham for the details.
Storage groups, expiration, and free space settings
The "global" setting "Extra Disk Space," specifies the amount of extra space to keep available on each filesystem, not a total amount of extra space to keep available across all filesystems. Therefore, if the "Extra Disk Space" is set to 3GB, it should be keeping 3GB available on all filesystems (to which Myth is recording at any particular time).
That parenthetical can actually be very important. If Myth is not recording to a filesystem, it does not autoexpire programs to make room for the data that some other process is writing to that filesystem. Therefore, until a recording starts and is being written to the filesystem in question, no programs will be expired from that filesystem.
Documentation initially copied from Installing and using MythTV.