Setup General

Previous	Up	Next
User Manual:Setting Up	User Manual:Index	User Manual:Detailed configuration Frontend

Backend

MythTV Detailed Backend Configuration v. 0.21. (Incomplete)

Introduction

This section takes you through a detailed walk through 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:

MythTV Structure: capture cards

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.

MythTV sources

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

MythTV Inputs

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, automagically 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...

MythTV Channels

Channels Editor: 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 agin is beyond the scope of this intro!

Now, with all those basic concepts in place, let's move on to the next section!

MythTV Backend

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.

Communications Protocol

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 procotol here. Work on defining the Myth Protocol is also being performed on this Wiki.

Backend Configuration

The MythTV Backend configuration has two main objectives

Tell MythTV what TV Capture/Tuner cards to use
Populate the Myth Database with information about channels and tuning information

There are additional items that can be configured, but without successfully achieving the above two steps you will not be able to get Live TV.

Running mythtv-setup

Configure the Myth backend like so

> /usr/bin/mythtv-setup

You will now see the GUI for MythTV to setup the backend server and in particular the channel tuning for our broadcast streams. You will need to set up:

General — General Backend settings, most user can use the defaults
Capture Cards — you will configure your capture cards/devices here
Video Sources — create guide data.
Input connections — connect the Capture Card name to the Video Source
Channel Editor — scan for your channels here
Storage Groups — Configure which folders your recordings will be saved.

Configuration Screens

General

Host Address Backend Setup

Setting	Default Value	Settings Page's Description	Additional Comments
Host Address Backend Setup
IP address for mythtv	127.0.0.1	Enter the IP address of this (backend) machine. Use an externally accessible address if you are going to be running a frontend or Slave Backend on a different machine than this one. (ie, not 127.0.0.1)	MythTV is made up of two major components, the Backend and the Frontend. If you run the Backend and Frontend on the same machine then you can leave the setting at its default value of 127.0.0.1. This is referred to as the local loopback address which is reserved for networking within a single machine. If you run multiple frontends, or run frontends over network connections on different machines, then you will need to set this to the backend machines' static IP address. This value will be determined by your TCP/IP Network addressing scheme.
Port the server runs on	6543	Unless you’ve got a good reason to, don’t change this.	As noted here you don't need to change this.
Port the server shows status on	6544	Port which the server will listen to for HTTP requests. Currently, it shows a little status information.	You can connect to your MythTV box via a web browser at the machine's IP and this port. It shows some information on the status of the box but you should configure MythWeb for more advanced purposes.
Security Pin (Required)	0000	You will need to enter this PIN to authenticate to your backend.	When using a remote frontend MythTV will auto discover your backend. For security you must entier this PIN into the frontend to gain access. This feature removes the need for the mysql.txt file in Prior verions (<=.20) Use four zero's (0) to disable this feature.
Master Server IP address	127.0.0.1	The IP address of the master backend server. All frontend and non-master backend machines will connect to this server. If you only have one backend, this should be the same IP address as above.	If you're running only a frontend, set the IP address for your backend here.
Port the master server runs on	6543	Port which the server will listen to for HTTP requests. Currently, it shows a little status information.	If you're running only a frontend, set the port for your backend here.

Locale Settings

Setting	Default Value	Settings Page's Description	Additional Comments
Locale Settings
TV format	NTSC	The standard to use for viewing TV.	Other choices include: ASTC, PAL, SECAM, PAL-NC, PAL-M, PAL-N, NTSC-JP. Be sure to set to the proper format for your region.
VBI format	None	VBI stands for Vertical Blanking Interrupt. VBI is used to carry Teletext and Closed Captioning data.	In TV broadcasting not all of the available lines in each frame of the picture are used. For example in CCIR systems (PAL and SECAM)25 lines per field (50 per frame) are specified for other uses. The remaining lines can be used for data broadcasting, and are typically used for closed caption or teletext. You may sometimes notice a squiggly black and white line or cube right at the top of the screen in a transmission; this is data being transmitted. In some countries, specific data broadcasting companies have exclusive rights on the use of the VBI lines. Options are None, PAL Teletext,
Channel frequency table	us-cable	Select the appropriate frequency table for your system. If you have an antenna, use a “-bcast” frequency.	Other choices include: us-bcast, us-cable-hrc, japan-bcast, japan-cable, europe-west, europe-east, italy, newzealand, australia, ireland, france, china-bcast, southafrica, argentina, australia-optus.
Time offset for XMLTV listings	None	If your local timezone does not match the timezone returned by XMLTV, use this setting to have mythfilldatabase adjust the program start and end times. None disables this feature, Auto automatically detects your local timezone.	Leave this alone if you're an American using the SchedulesDirect xml service.

Miscellaneous Settings

Setting	Default Value	Settings Page's Description	Additional Comments
Miscellaneous Settings
Master Backend Override	Checked	If enabled, the master backend will stream and delete files if it finds them in the video directory. Useful if you are using a central storage location, like a NFS share, and your slave backend isn’t running.	This is the meat of the subject
Follow Symbolic links when deleting files	Not checked	This will cause Myth to follow symlinks when recordings and related files are deleted, instead of deleting the symlink and leaving the actual file.	This is the meat of the subject
Delete Files Slowly	Not checked	Some filesystems use a lot of resource when deleting large recording files. This option makes Myth delete the file slowly on this backend to lessen the impact.	Use this option if you expericane video studder while Myth deletes recordings in the backround.
HD Ringerbuffer size (kb)	4700	The HD device ringbuffer allows the backend to weather moments of stress. the larger the ringbuffer, the longer the moments of stress can be. However, setting this too large can cause swapping, which is detrimental.	The default setting should be used in normal conditions. If you experience crashes when watching HD try increase this. You may need a stronger signal to eliminate the errors.
Miscellaneous Status Application	blank	External Application or script that outputs extra information for inclusion in the backend status page. See contrib/misc_status_info/README	no comments.
Disable Firewire Reset	Unchecked	By default MythTV will reset the firewire bus when a firewire recorder stops responding to commands. But if this causes problems you can disable this here for Linux firewire recorders.	no comments.

Shutdown/Wakeup Options

Setting	Default Value	Settings Page's Description	Additional Comments
Shutdown/Wakeup Options
Startup command	(empty)	This command is executed right after starting the backend. As a parameter '$status' is replaced by either 'auto' if the machine was started or 'user' if a user switched it on.	You may want to have post-startup tasks execute autonomously once the backend server has fully initialized. Use this parameter to specify a script that will get executed along with the backed server startup routines.
Block shutdown before client connected	Checked	If set, the automatic shutdown routine will be disabled until a client connects.	If you have shutdown wakeup enabled, the backend will normally check to see if its busy before it shuts down. Of course if you have just turned your machine on manually then you don't want it to shut down before you have had a chance to start the frontend. Once the frontend has been started then the shutdown command will take effect as soon as the frontend closes down. This means that you only need to exit the frontend and the machine will go down. With MythTV 0.18 this created a problem with Mythweb, in that as soon as Mythweb connected to a backend which had no frontend process attached, it would think that a frontend connected then disconnected and consequently shut down. This has been fixed in 0.19.
Idle timeout (secs)	0	The amount of time the master backend idles before it shuts down all backends. Set to 0 to disable auto shutdown.	MythTV can have multiple backends for the hardcore recording guy. Quite nice if you want to record lots of stuff at one time or if you are just a collector of all things broadcast. One of these backend machines will be designated as the Master Backend. This parameter controls how long the master backend idles, ie is not recording, transcoding or serving frontends before it decides to shut down all backends.
Max. wait for recording (min)	15	The amount of time the master backend waits for a recording. If it's idle but a recording starts within this time period, the backends won't shut down.	You don't want the machine to think its idle only to find that by the time it has shut down it has to start again to record the next schedule. This parameter tells the system to wait a period of time just in case a recording is due.
Startup before rec. (secs)	120	The amount of time the master backend will be woken up before a recording starts.	You often want to start a scheduled recording before it's actually scheduled according to the guide data. This is just in case it starts early or because you need to allow your machine time to boot in a wake up to record scenario. This parameter sets how much time you want to start the backend before the scheduled recording.
Wakeup time format	hh:mm yyyy-MM-dd	The format of the time string passed to the 'setWakeuptime Command' as $time. See QT::QDateTime.toString() for details.	Set this parameter to be the same as that expected by the BIOS clock.
Command to set Wakeup Time	Blank	The command used to set the time (passed as $time) to wake up the master backend.	This command needs to call an external script. Here is an example command ' sudo /usr/bin/mythsettime $time where mythsettime is an external script that sets the wakeup command parameters in the bios. Here is the mythsettime script contents sudo echo $1 > /home/mythtv/myth.time sudo echo $1 > /proc/acpi/alarm
Server halt command	sudo /sbin/halt -p	The command used to halt the backends.	This command needs to call an external script. Here is an example command ' sudo /usr/sbin/mythshutdown where mythshutdown is an external script that shuts the machine down. Here is the mythshutdown script contents sudo /sbin/halt -p
Pre Shutdown check-command	Blank	A command executed before the backends would shutdown. The return value determines if the backends can shutdown. 0 - yes, 1 - restart idling, 2 - reset the backends to wait for a frontend.	Your machines may be doing other things such as Samba file sharing or streaming music that are not MythTV related. In this case you will want to have script here that checks stuff before it shuts down. If you want to run the check on master and slave backend, you can use /usr/local/bin/myth-preshutdown.sh && ssh slavebackendhostname /usr/local/bin/myth-preshutdown.sh after setting up ssh authentication without passwords from master backend to slave backend.

WakeOnLan settings

MasterBackend

Reconnect wait time (secs):

Count of reconnect tries:

Wake Command

Wake command for slaves:

Job Queue (Host-Specific)

Maximum simultaneous jobs on this backend:

Run Jobs only on original recording host

Job Queue Check frequency (in seconds)

CPU Usage

Allow Commercial Detection jobs

Allow User Job #1 jobs

Allow User Job #2 jobs

Allow User Job #3 jobs

Allow User Job #4 jobs

Job Queue (Global)

Run Jobs only on original recording backend.

Start Auto-commercial Flagging jobs when the recording starts.

Commercial Flagger command:

Transcoder command:

Run Transcode Jobs before Auto-Commericial Flagging

Save origional files after transcoding (globally)

Job Queue (Job Commands)

User Job #1 Description:

User Job #1 Command:

User Job #2 Description:

User Job #2 Command:

User Job #3 Description:

User Job #3 Command:

User Job #4 Description:

User Job #4 Command:

Capture Cards

General configuration

Incomplete, needs to be expanded. Please help to fill the gaps or discuss the issue on the talk page