User Manual:MythTV structure
|User Manual:Setting Up||User Manual:Index||User Manual:Detailed configuration Frontend|
This page is up-to-date to MythTV version 0.20
This manual takes you through a detailed walk through into the various backend configuration options. Before doing this, a few ground concepts and terms should be explained so that the backend setup tasks sound logical to you:
The backend process (mythbackend) is the portion of the system that handles the Video capture cards as well as Scheduling Recordings on those cards, Commercial Flagging, and transcoding. The backend process interacts with the Database and the hardware primarily.
As with the MythFrontend, there can be multiple backends. One backend process is designated as the master backend. This is usually the first backend installed on a system. This backend is responsible for coordinating the activities of the other backends known as slaves. This is especially true for scheduling as the master backend will determine the best distribution of programs across all available tuners. Each backend can have any number of tuners. Commercial Flagging can be distributed across different backends, thereby spreading the load of that process.
There is no requirement for direct user interaction with the backend. The backend can use local Hardware/File Storage or have it mounted from another system. If remotely mounted, network performance should be considered as there will be considerable traffic on the network as recordings are stored and retrieved by the backend process.
The backend and frontend communicate using their own Myth Protocol. The developer of Win Myth, a windows frontend to MythTV for playing recordings on Windows, has documented his workings on the protocol here. Work on defining the Myth Protocol is also being performed on this Wiki.
In order to enable its great flexibility, MythTV uses a very modular approach when it comes to its internal architecture. This - unfortunately? - also means that the MythTV administrator - You! - has to get familiar with this architecture if he/she wants 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): capture cards 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 it allows you to install several capture cards at once on your system, thus allowing you to merge content from many different origins on the same box: DVB, Analog TV, IPTV, etc. Moreover, you can also install several identical -or similar, as long as they receive similar channels- capture cards on the same system, in order to allow recording a program (or several if you install more cards) while watching another.
Next in line are "Video Sources": video sources is a slightly misleading name: those are actually sources for Electronic Program Guide data: MythTV knows how to extract EPG from capture cards that support this, but since broadcast EPG data is usually fairly limited in terms of timespan and content, 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 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 -.
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). Beware, though: you should not link several different types of capture cards with the same source (for example, a DVB USB dongle + IPTV streaming from your ISP + PCI Analog TV capture card), or MythTV will get totally confused. AFAIK, the only 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, or all Analog, etc) and are meant to duplicate the number of tuners in order to enable simultaneous recording and watching.
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 out 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.
You may create additional Storage Groups to store specific recordings in their own directories. Storage Groups are edited via the 'Storage Directories' section of mythtv-setup. You may want 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.
You can also create multiple Storage Groups 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.
You can also create a special 'LiveTV' Storage Group. If a LiveTV Storage Group directory exists, it will be used instead of putting LiveTV recordings in the Default Storage Group, allowing you to put your LiveTV recordings on their own filesystem. This is similar to the old MythTV method which used a RingBuffer for LiveTV.
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 you have more than one directory 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 you set the "Extra Disk Space" 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.