Difference between revisions of "Setup General"

Revision as of 16:56, 8 August 2017

This page is up-to-date as of MythTV version 29, the current release is 34.0

Introduction

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:

With the backend of MythTV we mean the portion of the system that enables you to use capture devices as well as Scheduling Recordings on those cards, Commercial Detection, and transcoding. In short the backend process interacts with the Database and the hardware primarily.

The frontend and backend may be physically on the same hardware. This is the normal case with somebody starting out with a new system. In this case, backend and frontend setup are done on the same machine.

As with the Mythfrontend, there can be multiple backends. One backend computer 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 Detection can be distributed across different backends, thereby spreading the load of that process.

The backend setup program is run on each backend computer. It uses a user interface that is designed for a TV screen, like the frontend. If the backend does not have a physical display attached, the backend setup can still be run remotely from another computer, using ssh Forwarding.

If you installed MythTV from the MythBuntu or Ubuntu package the backend will run even if no setup has been done. If you compiled from source the backend will not run until you have setup at least one tuner.

Permissions

If you are using a device that has a Linux driver, such as a DVB, V4L, HD PVR, you will need to add your user to the video group, so that the backend setup can access the video device. The user that runs the backend also needs this, but if you installed from a package this would probably already have been done for the backend user.

sudo adduser userid video

Themes

The MythTV front end and the MythTV setup program support Themes which control the way the user interface is presented. You can download and select a theme in the frontend, and the theme will also be used for MythTV setup. The theme is stored in your home directory, so you need to use the same login user id for the frontend and for setup, if you want to use the theme for MythTV Setup.

To change the theme you will have to run the frontend. If your backend is not running the frontend will display a large error message. However you can ignore this error message and still proceed with changing the theme. The error message that the backend is not running will redisplay every few seconds, just ignore it and select your theme, then exit from the front end.

Running mythtv-setup

While running the backend setup, the backend must be shut down. Otherwise changing existing card inputs, deleting anything, or scanning for channels may not work. If you installed the Ubuntu or Mythbuntu package, a shell script will take care of that for you. If you built from source you should make sure to stop the backend before running setup.

Configure the Myth backend like so

/usr/bin/mythtv-setup

or select "MythTV Backend Setup" from the Display Manager menu.

The first time you run this on a new database, you will be prompted to select your Country and Language. If setup exits after this, run it again. You may be prompted to upgrade your database. Confirm the upgrade.

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

These screens are designed for use with a TV and keyboard. The mouse will not work consistently. With the keyboard use up and down arrow to move between fields. Use the left and right arrow to select options from a list.

These are the top level menu items available for configuration:

General — General Backend settings
Capture Cards — Add and configure your capture devices here
Recording Profiles
Video Sources — create guide data. This may require you to subscribe to an online service that provides programming information specific to your location and TV service.
Input connections — tell your Capture Card(s) to which Video Source they should connect. (If you are setting up an IR blaster, you will need to add a script here that controls it.)
Channel Editor — scan and configure your channels here
Storage Directories — Configure which folders your recordings will be saved to.
System Events

The General backend settings are described here. The rest of the settings are described in the next article.

Slave Backends

There are two types of backends:

Master backend: you need at least one master backend on any MythTV setup
Slave (remote) backend: Any additional backends will be Slave backends.

Most users will have a master backend only. Remote backends are an advanced usage.

Ensure that you've granted access to the same MySQL database that the master backend uses for remote backends. This is also needed for remote frontends. Make sure that you have the correct hostname/IP address for the database server in the "Database Configuration" screen of the mythtv-setup application on this remote backend.

Remote backends may run a local MySQL daemon for non MythTV purposes, however, the remote backend must access the same MySQL server that the master backend does. Failure to access the correct database will cause unexpected behavior such as empty "Watch Recordings" lists and a failure to locate the Video Sources defined on the master backend. Modify the config.xml file on all remote backends to ensure that <Host> is set to the hostname/IP address of the MySQL server. Caveat: You may make a remote backend the primary MySQL server, or run a non-MythTV database on a remote backend as long as you have edited the config.xml file on all systems and made it consistent. There can be only one authoritative MySQL database in a MythTV system - errors such as the ones above ensue if backends and frontends have differing ideas of which MySQL database they should talk to.

Make sure that the IP addresses on the General setup screen are accurate. If the remote backend can't communicate with the master backend due to IP address misconfiguration then MythTV will not function properly. A backend becomes a remote when the Master Backend IP address is different than either the Local Backend IPv4 address (or IPv6 address.)

Configuration of a non-master backend follows the same general procedure as that of the master backend, with the exception that you skip over the "Video Sources" step. All possible video sources need to be defined on the master backend system; only the master backend will query a listings provider to obtain guide data for all the non-master backends. In almost all cases, "Storage Groups" are configured on the master backend too. For a detailed writeup, see Storage Groups

General

The General settings is where you will set up the core settings of your backend. In case you are running a basic backend/frontend combined setup, you will most probably want to leave the default settings for most of this section, but in case your setup involves several separate backends and frontends, this is where you will determine the role of the backend you're currently configuring.

Host Address Backend Setup (v0.28)

This description applies to version 0.28 of MythTV and prior versions.

Setting	Default Value	Settings Page's Description	Additional Comments
*Local Backend (MachineName)*
IPv4 address	127.0.0.1	Enter the IP address of this machine. Use an externally accessible address (ie, not 127.0.0.1) if you are going to be running a frontend on a different machine than this one. Note, in IPv6 setups, this is still required for certain extras such as UPnP.	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.
IPv6 address	::1	Enter the IPv6 address of this machine. Use an externally accessible address (ie, not ::1) if you are going to be running a frontend on a different machine than this one.	Only change this if you plan to use IPv6. For more information on IPv6 see Enable IPv6.
Listen on Link-Local addresses	Checked	Enable servers on this machine to listen on link-local addresses. These are auto-configured addresses and not accessible outside the local network. This must be enabled for anything requiring Bonjour to work.	You should normally leave this enabled.
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.
Status port	6544	Port on which the server will listen for HTTP requests, including backend status and MythXML requests.	As above, don't change. Used by the Services API. Users include mythweb and 3rd party clients (Android/IOS/Kodi...)
Security Pin (Required)	blank	PIN code required for a frontend to connect to the backend. Blank prevents all connections; 0000 allows any client to connect.	When using a remote frontend MythTV will auto discover your backend. For security you must enter this PIN into the frontend to gain access. This feature removes the need for manually configuring the $HOME/.mythtv/config.xml. Use four zero's (0) to allow any client to connect and request database credentials. Leave the setting blank to forbid any client from receiving database credentials. If you set this other than 0000 you will have to setup config.xml on your remote frontend machines.
Master Backend
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. YOu can use an IPv4 or an IPv6 address here.	This must match the value of IPv4 or IPv6 address that was set on the backend configuration of the Master backend.
Port	6543	Unless you’ve got a good reason to, don’t change this.	This must match the port the sserver runs on that was set on the backend configuration of the Master backend.

Host Address Backend Setup (v29)

This description applies to version 29 of MythTV.

Setting	Default Value	Settings Page's Description	Additional Comments
Port	6543	Unless you’ve got a good reason to, don’t change this.	As noted here you don't need to change this.
Status port	6544	Port on which the server will listen for HTTP requests, including backend status and MythXML requests.	As above, don't change. Used by the Services API. Users include mythweb and 3rd party clients (Android/IOS/Kodi...)
Security Pin (Required)	blank	PIN code required for a frontend to connect to the backend. Blank prevents all connections; 0000 allows any client to connect.	When using a remote frontend MythTV will auto discover your backend. For security you must enter this PIN into the frontend to gain access. This feature removes the need for manually configuring the $HOME/.mythtv/config.xml. Use four zero's (0) to allow any client to connect and request database credentials. Leave the setting blank to forbid any client from receiving database credentials. If you set this other than 0000 you will be prompted for it in the frontend startup, or you can manually setup config.xml on your remote frontend machines.
Allow Connections from all Subnets	Unchecked	Allow this backend to receive connections from any IP address on the internet. NOT recommended for most users. Use this only if you have secure IPV4 and IPV6 firewalls.	Most users should leave this unchecked. Otherwise your MythTV system may be accessible from the internet. If you do want it accessible from other subnets, you should set up firewalls to protect yourself.
Listen on All IP Addresses	Checked	Allow this backend to receive connections on any IP Address assigned to it. Recommended for most users for ease and reliability.	Most users should leave this checked. This avoids youi having to select specific listen addresses and also allows communication to proceed even if the backend starts before your IO addresses are initialized.
*IP Addresses (Only accessible if Listen on All IP Addresses* is unchecked)**
IPv4 address	127.0.0.1	Enter the IP address of this machine. Use an externally accessible address (ie, not 127.0.0.1) if you are going to be running a frontend on a different machine than this one. Note, in IPv6 setups, this is still required for certain extras such as UPnP.	If you choose not to listen on all ip addresses, you will have to select one here. If you have remote frontends you will have to use a value other than the default.
Listen on IPv6 address	::1	Select an IPv6 address for listening. Use an externally accessible address (ie, not ::1) if you are going to be running a frontend on a different machine than this one.	Only change this if you plan to use IPv6. For more information on IPv6 see Enable IPv6.
Listen on Link-Local addresses	Checked	Enable servers on this machine to listen on link-local addresses. These are auto-configured addresses and not accessible outside the local network. This must be enabled for anything requiring Bonjour to work.	You should normally leave this enabled.
Host Address Backend Setup continued
Primary IP address / DNS name	127.0.0.1	The Primary IP address of this backend server. You can select an IP address from the list or type a DNS name or host name. Other systems will contact this server using this address. If you use a host name make sure it is assigned an ip address other than 127.0.0.1 in the hosts file.	Select from the list an IP address that you want other systems to use to contact this backend. You can also type a host name or DNS name.
This server is the Master Backend	Checked	Enable this if this is the only backend or is the master backend server. If enabled, all frontend and non-master backend machines will connect to this server. To change to a new master backend, run setup on that server and select it as master backend.	Enable this on your master backend
Master Backend Name		Host name of Master Backend. This is set by selecting "This server is the Master Backend" on that server	You cannot update this directly. It is set when you select the prior check box.

Locale Settings

Setting	Default Value	Settings Page's Description	Additional Comments
TV format	NTSC	The standard to use for viewing TV.	Other choices include: ATSC, PAL, SECAM, PAL-NC, PAL-M, PAL-N, NTSC-JP. Be sure to set to the proper format for your region.
VBI format	NTSC Closed Caption	VBI stands for vertical blanking interval, the time between tracing the last line on the display and returning to the first, when the CRT's electron beam is turned off (blanked). The 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, NTSC closed caption
Channel frequency table	us-bcast	Select the appropriate frequency table for your system. If you have an antenna, use a “-bcast” frequency.	Other choices include: us-bcast, us-cable, us-cable-hrc, us-cable-irc, japan-bcast, japan-cable, europe-west, europe-east, italy, newzealand, australia, ireland, france, china-bcast, southafrica, argentina, australia-optus, singapore, malaysia, israel-hot-matav, try-all.

Miscellaneous Settings

Setting	Default Value	Settings Page's Description	Additional Comments
File Management 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.	For a single backend setup, leave this checked. This means that all files will stream from the master backend. It also means all files must be available on the master backend. If you have slave backends either uncheck this or if you check it make sure that all storage directories are mounted on the master backend.
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.	In a normal recording setup mythtv does not use symbolic links so this will have no effect. Normally you should leave this unchecked unless you have your own file manipulation going on outside of MythTV.
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.	Select this if using ext3 file system for recordings. It is not needed with ext4.
HD Ringerbuffer size (kb)	4700	The HD device ring buffer allows the backend to weather moments of stress. the larger the ring buffer, 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. Modern machines have gigabytes of memory so this can safely be increased if you are experiencing pauses during playback.
Storage Group disk scheduler	Balanced free space	This setting controls how the Storage Group scheduling code will balance new recordings across directories. 'Balanced Free Space' is the recommended method for most users.	See Setup Storage Directories#Storage Group Disk Scheduler for full details.
UPnP Server Settings
Video Content to show a WMP Client	Recordings	Which tree to show a Windows Media Player client when it requests a list of videos.	MythTV supports watching of recordings or Videos with Windows Media Player and other applications. This determines whether they can see recordings or Videos.
Other Settings
Miscellaneous Status Application	blank	External application or script that outputs extra information for inclusion in the backend status page. See http://www.mythtv.org/wiki/Miscellaneous_Status_Information	See Miscellaneous Status Information
Disable Automatic Database Backup	Not Checked	If enabled, MythTV will not backup the database before upgrades. You should therefore have your own database backup strategy in place.	It is recommended to leave this unchecked.
Disable Firewire Reset	Not Checked	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.	Unfortunately Firewire recording is somewhat unreliable, whether this option is selected or not.

EIT Scanner Options

Setting	Default Value	Settings Page's Description	Additional Comments
EIT transport timeout (mins)	5	Maximum time to spend waiting (in minutes) for listings data on one digital TV channel before checking for new listings data on the next channel.	For information on using EIT to obtain program listings see EIT.
Backend idle before EIT crawl (secs)	60	The minimum number of seconds after a recorder becomes idle to wait before MythTV begins collecting EIT listings data.	For information on using EIT to obtain program listings see EIT.

Shutdown/Wakeup Options

Setting	Default Value	Settings Page's Description	Additional Comments
Startup command	blank	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.
Idle timeout (secs)	0	The number of seconds the master backend idles before it shuts down all other backends. Set to 0 to disable automatic shutdown.	If you want the backend to shut down when idle you must set this value as non zero.
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 recording (secs)	120	The number of seconds the master backend will be woken up before a recording starts.	this is the amount of time you are allowing for the backends to boot up and be ready for recording. 120 seconds is cutting it a bit fine. 300 secodns would eb a good choice, and maybe more if you have slave backends that also do recording.
Wakeup time format	hh:mm yyyy-MM-dd	The format of the time string passed to the 'Command to set wakeup time' as $time. See QT::QDateTime.toString() for details. Set to 'time_t' for seconds since epoch.	Set this parameter to be the same as that expected by the Command to set Wakeup Time below.
Command to set Wakeup Time	blank	The command used to set the wakeup time (passed as $time) for the Master Backend	If you have set an idle timeout, the backend will shut down. You must set up a script to set a wakeup time and give the script name here. See ACPI Wakeup for details on setting a wakeup command.
Server halt command	sudo /sbin/halt -p	The command used to halt the backends.	This command needs to call an external script. If you are using sudo here you will need to set up permission for the backend to run the command without a password.
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 a script here that checks stuff before it shuts down. Also if you are logged into the machine doing some work you do not want it to shut down.

Backend Wakeup settings

Setting	Default Value	Settings Page's Description	Additional Comments
Master Backend These settings are only used when your database is running but your master backend is not. If the master backend and database automatically start with the backend machine, then configure the datbase wakeup in the frontend settings and leave this out. If the master database is on a separate server, configure the wakeup settings for the database in the frontend and configure the master backend wakeup settings here.
Delay between wake attempts (secs)	0	Length of time the frontend waits between tries to wake up the master backend. This should be the time your master backend needs to startup. Set to 0 to disable.	Set a value to enable the wake up, and allow enough time for the backend to start.
Wake Attempts	5	Number of times the frontend will try to wake up the master backend.	Normally only 1 attempt would be required. In case you happen to invoke a remote frontend while the backend is in the process of shutting down, it may not work and you may need more than 1 attempt.
Wake Command	blank	The command used to wake up your master backend server (e.g. sudo /etc/init.d/mythtv-backend restart).	The example command may be misleading. This is a command that will be run on a frontend to wake a master backend. It should normally invoke a wake-on-lan command.
Slave Backends
Sleep Command	blank	The command used to put this slave to sleep. If set, the master backend will use this command to put this slave to sleep when it is not needed for recording.	Set this while running setup on the slave backend machine.
Wake Command	blank	The command used to wake up this slave from sleep. This setting is not used on the master backend.	Set this while running setup on the slave backend machine.

Backend Control

Setting	Default Value	Settings Page's Description	Additional Comments
Backend Control Settings here are run on each backend, master or slave.
Backend stop command	killall mythbackend	The command used to stop the backend when running on the master backend server (e.g. sudo /etc/init.d/mythtv-backend stop)	This command is used to stop the backend when setup is run and you choose to close the backend. Note: when you use the Ubuntu or Mythbuntu package there is a script that invokes backend setup and it does not use this setting for stopping the backend.
Backend start command	mythbackend	The command used to start the backend when running on the master backend server (e.g. sudo /etc/init.d/mythtv-backend start).	This command is used to restart the backend when setup is closed and you had selected for setup to close the backend. Note: Like the stop command above this is not used when you installed the Mythbuntu or Ubuntu package.

Job Queue (Backend-Specific)

Setting	Default Value	Settings Page's Description	Additional Comments
Settings here are run on each backend, master or slave.
Maximum simultaneous jobs on this backend	1	The Job Queue will be limited to running this many simultaneous jobs on this backend.	Adjust this according to the power of this backend machine.
Job Queue check frequency (secs)	60	When looking for new jobs to process, the Job Queue will wait this many seconds between checks.	There is probably no reason to change this.
Job Queue start time	0:00	This setting controls the start of the Job Queue time window, which determines when new jobs will be started.	You can limit the time periods when jobs will run.
CPU usage	Low	This setting controls approximately how much CPU jobs in the queue may consume. On 'High', all available CPU time may be used, which could cause problems on slower systems.	You can limit the time periods when jobs will run.
Allow metadata lookup jobs	Checked	If enabled, allow jobs of this type to run on this backend.
Allow commercial-detection jobs	Checked	If enabled, allow jobs of this type to run on this backend.
Allow transcoding jobs	Checked	If enabled, allow jobs of this type to run on this backend.
Allow User Job #1 jobs	Not Checked	If enabled, allow jobs of this type to run on this backend.	User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
Allow User Job #2 jobs	Not Checked	If enabled, allow jobs of this type to run on this backend.	User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
Allow User Job #3 jobs	Not Checked	If enabled, allow jobs of this type to run on this backend.	User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
Allow User Job #4 jobs	Not Checked	If enabled, allow jobs of this type to run on this backend.	User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.

Job Queue (Global)

Setting	Default Value	Settings Page's Description	Additional Comments
Run Jobs only on original recording backend	Not Checked	If enabled, jobs in the queue will be required to run on the backend that made the original recording.	If you leave this unchecked, you have to make sure that all recording directories are available on all backends, via NFS or another mechanism.
Start auto-commercial-detection jobs when the recording starts	Not Checked	If enabled, and Auto Commercial Detection is ON for a recording, the flagging job will be started as soon as the recording starts. NOT recommended on underpowered systems.
Commercial-detection command	mythcommflag	The program used to detect commercials in a recording. The default is 'mythcommflag' if this setting is empty.	See User Jobs for arguments that can be used. Equivalent default command: mythcommflag -j %JOBID% -V %VERBOSELEVEL%
Transcoder command	mythtranscode	The program used to transcode recordings. The Defaults is 'mythtranscode' if this setting is empty.	See User Jobs for arguments that can be used. Equivalent default command: mythtranscode -j %JOBID% -V %VERBOSELEVEL% -p %TRANSPROFILE% [-l] ('-l' is passed only if cutlists are to be used in transcoding)
RunRun transcode jobs before auto commercial detection	Not Checked	If enabled, and if both auto-transcode and commercial detection are turned ON for a recording, transcoding will run first; otherwise, commercial detection runs first.
Save original files after transcoding (globally)	Not Checked	If enabled and the transcoder is active, the original files will be renamed to .old once the transcoding is complete.

Job Queue (Job Commands)

Setting	Default Value	Settings Page's Description	Additional Comments
User Job #1 description	User Job #1	The description for this User Job.	If you create a user job, change this to a name for the user job. This name is shown in the frontend and other places when referring to the job.
User Job #1 command	blank	The command to run whenever this User Job number is scheduled.	This is typically a script you have created to do some task after a recording is complete.
User Job #n description	User Job #n	The description for this User Job.	There are prompts for 4 user jobs, 1 - 4.
User Job #n command	blank	The command to run whenever this User Job number is scheduled.	There are prompts for 4 user jobs, 1 - 4.

Program Schedule Downloading Options

Setting	Default Value	Settings Page's Description	Additional Comments
Automatically update program listings	Checked	If enabled, the guide data program will be run automatically.	If you want the backend to invoke the guide data program once a day, enable this. Many people use a cron script or other method of running it, in which case this should be unchecked.
Guide data program	mythfilldatabase	Use 'mythfilldatabase' or the name of a custom script that will populate the program guide info for all your video sources.	This program will run under the same user id as the backend. If you are using xmltv for your guide data you will have to make sure that the data in the home directory that set up xmltv is available to mythfilldatabase.
Guide data arguments	blank	Any arguments you want passed to the guide data program.	See mythfilldatabase or run "mythfilldatabase -h" for details of valid arguments for mythfilldatabase. When using schedules direct, we recommend using the --dd-grab-all argument.
Guide data program execution start	0	This setting and the following one define a time period when the guide data program is allowed to run. For example, setting start to 11 and end to 13 would mean that the program would only run between 11:00 AM and 1:59 PM.
Guide data program execution end	23	This setting and the preceding one define a time period when the guide data program is allowed to run. For example, setting start to 11 and end to 13 would mean that the program would only run between 11:00 AM and 1:59 PM.
Run guide data program at time suggested by the grabber.	Checked	If enabled, allow a DataDirect guide data provider to specify the next download time in order to distribute load on their servers. Guide data program execution start/end times are also ignored.	Currently Schedules Direct always suggests the next time as 24 hours later, so this is not very useful.

Other Setup Pages

The rest of the setup pages are described in the next chapter, User Manual:MythTV structure.

Difference between revisions of "Setup General"

Revision as of 16:56, 8 August 2017

Contents

Introduction

Permissions

Themes

Running mythtv-setup

Slave Backends

General

Host Address Backend Setup (v0.28)

Host Address Backend Setup (v29)

Locale Settings

Miscellaneous Settings

EIT Scanner Options

Shutdown/Wakeup Options

Backend Wakeup settings

Backend Control

Job Queue (Backend-Specific)

Job Queue (Global)

Job Queue (Job Commands)

Program Schedule Downloading Options

Other Setup Pages

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Wiki Navigation

Official Resources

Tools

Print/export

@@ Line 1: / Line 1: @@
-{{Navigate|User Manual:Setting Up|User Manual:Index|User Manual:Detailed configuration Frontend}}
+{{User Manual TOC}}
-Backend
+{{UpToDate 29}}
-MythTV Detailed Backend Configuration v. 0.21. (Incomplete)
+== Introduction ==
+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:
+With the backend of MythTV we mean the portion of the system that enables you to use [[Video capture card|capture devices]] as well as [[Scheduling Recordings]] on those cards, [[Commercial Detection]], and [[transcoding]]. In short the backend process interacts with the [[Database]] and the [[hardware]] primarily.
+The frontend and backend may be physically on the same hardware. This is the normal case with somebody starting out with a new system. In this case, backend and frontend setup are done on the same machine.
-== Introduction ==
+As with the [[Mythfrontend]], there can be multiple backends.  One backend computer 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 Detection]] can be distributed across different backends, thereby spreading the load of that process.
-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:
+The backend setup program is run on each backend computer. It uses a user interface that is designed for a TV screen, like the frontend. If the backend does not have a physical display attached, the backend setup can still be run remotely from another computer, using [[ssh Forwarding]].
-===MythTV Structure: capture cards===
+If you installed MythTV from the MythBuntu or Ubuntu package the backend will run even if no setup has been done. If you compiled from source the backend will not run until you have setup at least one tuner.
-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!
+==Permissions==
-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.
+If you are using a device that has a Linux driver, such as a DVB, V4L, HD PVR, you will need to add your user to the video group, so that the backend setup can access the video device. The user that runs the backend also needs this, but if you installed from a package this would probably already have been done for the backend user.
-===MythTV sources===
+<code>sudo adduser ''userid'' video</code>
-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 -.
+==Themes==
-===MythTV Inputs===
+The MythTV front end and the MythTV setup program support ''Themes'' which control the way the user interface is presented. You can download and select a theme in the frontend, and the theme will also be used for MythTV setup. The theme is stored in your home directory, so you need to use the same login user id for the frontend and for setup, if you want to use the theme for MythTV Setup.
-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.
+To change the theme you will have to run the frontend. If your backend is not running the frontend will display a large error message. However you can ignore this error message and still proceed with changing the theme. The error message that the backend is not running will redisplay every few seconds, just ignore it and select your theme, then exit from the front end.
-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...
+==Running mythtv-setup==
-===MythTV Channels===
+While running the backend setup, the backend must be shut down. Otherwise changing existing card inputs, deleting anything, or scanning for channels may not work. If you installed the Ubuntu or Mythbuntu package, a shell script will take care of that for you. If you built from source you should make sure to stop the backend before running setup.
-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.
+Configure the Myth backend like so
-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.
+<code>/usr/bin/mythtv-setup</code>
-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!
+or select "MythTV Backend Setup" from the Display Manager menu.
-Now, with all those basic concepts in place, let's move on to the next section!
+The first time you run this on a new database, you will be prompted to select your Country and Language. If setup exits after this, run it again. You may be prompted to upgrade your database. Confirm the upgrade.
-== MythTV Backend ==
+You will now see the GUI for MythTV to setup the backend server and in particular the channel tuning for our broadcast streams.
-The backend process (mythbackend) is the portion of the system that handles the [[Video capture card]]s as well as [[Scheduling Recordings]] on those cards, [[Commercial Flagging]], and [[transcoding]].  The backend process interacts with the [[Database]] and the [[hardware]] primarily.
+These screens are designed for use with a TV and keyboard. The mouse will not work consistently. With the keyboard use up and down arrow to move between fields. Use the left and right arrow to select options from a list.
-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.
+These are the top level menu items available for configuration:
-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.
+# General — General Backend settings
+# Capture Cards — Add and configure your capture devices here
+# Recording Profiles
+# Video Sources — create guide data. This may require you to subscribe to an online service that provides programming information specific to your location and TV service.
+# Input connections — tell your Capture Card(s) to which Video Source they should connect. (If you are setting up an IR blaster, you will need to add a script here that controls it.)
+# Channel Editor — scan and configure your channels here
+# Storage Directories — Configure which folders your recordings will be saved to.
+# System Events
-===Communications Protocol===
+The General backend settings are described here. The rest of the settings are described in the next article.
-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 [http://winmyth.sourceforge.net/mythprotocol.html here].  Work on defining the [[Myth Protocol]] is also being performed on this Wiki.
+==Slave Backends==
-===Backend Configuration===
+There are two types of backends:
-The MythTV Backend configuration has two main objectives
+* Master backend: you need at least one master backend on any MythTV setup
-* Tell MythTV what TV Capture/Tuner cards to use
+* Slave (remote) backend: Any additional backends will be [[User Manual:Setting Up#Slave Backend|Slave backends]].
-* 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.
+Most users will have a master backend only. Remote backends are an advanced usage.
-====Running [[Mythtv-setup | mythtv-setup]]====
+Ensure that you've granted access to the same MySQL database that the master backend uses for remote backends. This is also needed for remote frontends. Make sure that you have the correct hostname/IP address for the database server in the "Database Configuration" screen of the mythtv-setup application on this remote backend.
-Configure the Myth backend like so
+Remote backends may run a local MySQL daemon for non MythTV purposes, however, the remote backend '''must''' access the same MySQL server that the master backend does.
+Failure to access the correct database will cause unexpected behavior such as empty "Watch Recordings" lists and a failure to locate the Video Sources defined on the master backend. Modify the [[config.xml]] file on all remote backends to ensure that ''<Host>'' is set to the hostname/IP address of the MySQL server.  Caveat: You may make a remote backend the primary MySQL server, or run a non-MythTV database on a remote backend as long as you have edited the ''config.xml'' file on all systems and made it consistent.  There can be only one authoritative MySQL database in a MythTV system - errors such as the ones above ensue if backends and frontends have differing ideas of which MySQL database they should talk to.
-  > /usr/bin/mythtv-setup
+Make sure that the IP addresses on the General setup screen are accurate.  If the remote backend can't communicate with the master backend due to IP address misconfiguration then MythTV will not function properly.
+A backend becomes a remote when the ''Master Backend'' ''IP address'' is different than either the ''Local Backend'' ''IPv4 address'' (or ''IPv6 address''.)
-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:
+Configuration of a non-master backend follows the same general procedure as that of the master backend, with the exception that you skip over the "Video Sources" step. All possible video sources need to be defined on the master backend system; only the master backend will query a listings provider to obtain guide data for all the non-master backends. In almost all cases, "Storage Groups" are configured on the master backend too. For a detailed writeup, see [[Storage_Groups#Multiple_Backends|Storage Groups]]
-#General &mdash; General Backend settings, most user can use the defaults
+==General==
-#Capture Cards &mdash; you will configure your capture cards/devices here
-#Video Sources &mdash; create guide data.
-#Input connections &mdash; connect the Capture Card name to the Video Source
-#Channel Editor &mdash; scan for your channels here
-#Storage Groups &mdash; Configure which folders your recordings will be saved.
-====Configuration Screens====
+The General settings is where you will set up the core settings of your backend. In case you are running a basic backend/frontend combined setup, you will most probably want to leave the default settings for most of this section, but in case your setup involves several separate backends and frontends, this is where you will determine the role of the backend you're currently configuring.
-====General====
+===Host Address Backend Setup (v0.28)===
-=====Host Address Backend Setup=====
+This description applies to version 0.28 of MythTV and prior versions.
-{| border="1" cellspacing="0" cellpadding="5" align="center"
+{| class="wikitable" style="width: 100%;"
-| colspan="4" align="center" style="background: #efefef;" | '''Host Address Backend Setup'''
 |-
-! |Setting
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
-! |Default Value
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
-! |Settings Page's Description
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
-! |Additional Comments
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
 |-
-|IP address for mythtv
+| colspan="4" align="left" | '''Local Backend (''MachineName'')'''
+|-
+|IPv4 address
 | align="center" | 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)
+|Enter the IP address of this machine. Use an externally accessible address (ie, not 127.0.0.1) if you are going to be running a frontend on a different machine than this one. Note, in IPv6 setups, this is still required for certain extras such as UPnP.
 |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.
+|-
+|IPv6 address
+| align="center" | ::1
+|Enter the IPv6 address of this machine. Use an externally accessible address (ie, not ::1) if you are going to be running a frontend on a different machine than this one.
+|Only change this if you plan to use IPv6. For more information on IPv6 see [[Enable IPv6]].
+|-
+|Listen on Link-Local addresses
+| align="center" | Checked
+|Enable servers on this machine to listen on link-local addresses. These are auto-configured addresses and not accessible outside the local network. This must be enabled for anything requiring Bonjour to work.
+|You should normally leave this enabled.
 |-
 |Port the server runs on
@@ Line 94: / Line 113: @@
 |As noted here you don't need to change this.
 |-
-|Port the server shows status on
+|Status port
 | align="center" | 6544
-|Port which the server will listen to for HTTP requests. Currently, it shows a little status information.
+|Port on which the server will listen for HTTP requests, including backend status and MythXML requests.
-|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.
+|As above, don't change. Used by the [[Services API#What_is_the_Services_API|Services API]]. Users include ''mythweb'' and 3rd party clients (''Android''/''IOS''/''Kodi''...)
 |-
 |Security Pin (Required)
-| align="center" | 0000
+| align="center" | blank
-|  You will need to enter this PIN to authenticate to your backend.
+| PIN code required for a frontend to connect to the backend. Blank prevents all connections; 0000 allows any client to connect.
-|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.
+|When using a remote frontend MythTV will auto discover your backend.  For security you must enter this PIN into the frontend to gain access.  This feature removes the need for manually configuring the $HOME/.mythtv/config.xml. Use four zero's (0) to allow any client to connect and request database credentials.  Leave the setting blank to forbid any client from receiving database credentials. If you set this other than 0000 you will have to setup config.xml on your remote frontend machines.
 |-
-|Master Server IP address
+| colspan="4" align="left" | '''Master Backend'''
+|-
+|IP address
 | align="center" | 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.
+|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. YOu can use an IPv4 or an IPv6 address here.
-|If you're running only a frontend, set the IP address for your backend here.
+|This must match the value of IPv4 or IPv6 address that was set on the backend configuration of the Master backend.
 |-
-|Port the master server runs on
+|Port
 | align="center" | 6543
-|Port which the server will listen to for HTTP requests. Currently, it shows a little status information.
+|Unless you’ve got a good reason to, don’t change this.
-|If you're running only a frontend, set the port for your backend here.
+|This must match the port the sserver runs on that was set on the backend configuration of the Master backend.
 |-
 |}
-=====Locale Settings=====
+===Host Address Backend Setup (v29)===
-{| border="1" cellspacing="0" cellpadding="5" align="center"
+This description applies to version 29 of MythTV.
-|colspan="4" align="center" style="background: #efefef;" | '''Locale Settings'''
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
+|Port
+| align="center" | 6543
+|Unless you’ve got a good reason to, don’t change this.
+|As noted here you don't need to change this.
+|-
+|Status port
+| align="center" | 6544
+|Port on which the server will listen for HTTP requests, including backend status and MythXML requests.
+|As above, don't change. Used by the [[Services API#What_is_the_Services_API|Services API]]. Users include ''mythweb'' and 3rd party clients (''Android''/''IOS''/''Kodi''...)
+|-
+|Security Pin (Required)
+| align="center" | blank
+| PIN code required for a frontend to connect to the backend. Blank prevents all connections; 0000 allows any client to connect.
+|When using a remote frontend MythTV will auto discover your backend.  For security you must enter this PIN into the frontend to gain access.  This feature removes the need for manually configuring the $HOME/.mythtv/config.xml. Use four zero's (0) to allow any client to connect and request database credentials.  Leave the setting blank to forbid any client from receiving database credentials. If you set this other than 0000 you will be prompted for it in the frontend startup, or you can manually setup config.xml on your remote frontend machines.
 |-
-! |Setting
+|Allow Connections from all Subnets
-! |Default Value
+| align="center" | Unchecked
-! |Settings Page's Description
+|Allow this backend to receive connections from any IP address on the internet. NOT recommended for most users. Use this only if you have secure IPV4 and IPV6 firewalls.
-! |Additional Comments
+|Most users should leave this unchecked. Otherwise your MythTV system may be accessible from the internet. If you do want it accessible from other subnets, you should set up firewalls to protect yourself.
+|-
+|Listen on All IP Addresses
+| align="center" | Checked
+|Allow this backend to receive connections on any IP Address assigned to it. Recommended for most users for ease and reliability.
+|Most users should leave this checked. This avoids youi having to select specific listen addresses and also allows communication to proceed even if the backend starts before your IO addresses are initialized.
+|-
+| colspan="4" align="left" | '''IP Addresses (Only accessible if ''Listen on All IP Addresses'' is unchecked)'''
+|-
+|IPv4 address
+| align="center" | 127.0.0.1
+|Enter the IP address of this machine. Use an externally accessible address (ie, not 127.0.0.1) if you are going to be running a frontend on a different machine than this one. Note, in IPv6 setups, this is still required for certain extras such as UPnP.
+|If you choose not to listen on all ip addresses, you will have to select one here. If you have remote frontends you will have to use a value other than the default.
+|-
+|Listen on IPv6 address
+| align="center" | ::1
+|Select an IPv6 address for listening. Use an externally accessible address (ie, not ::1) if you are going to be running a frontend on a different machine than this one.
+|Only change this if you plan to use IPv6. For more information on IPv6 see [[Enable IPv6]].
+|-
+|Listen on Link-Local addresses
+| align="center" | Checked
+|Enable servers on this machine to listen on link-local addresses. These are auto-configured addresses and not accessible outside the local network. This must be enabled for anything requiring Bonjour to work.
+|You should normally leave this enabled.
+|-
+| colspan="4" align="left" | '''Host Address Backend Setup continued'''
+|-
+|Primary IP address / DNS name
+| align="center" | 127.0.0.1
+|The Primary IP address of this backend server. You can select an IP address from the list or type a DNS name or host name. Other systems will contact this server using this address. If you use a host name make sure it is assigned an ip address other than 127.0.0.1 in the hosts file.
+|Select from the list an IP address that you want other systems to use to contact this backend. You can also type a host name or DNS name.
+|-
+|This server is the Master Backend
+| align="center" | Checked
+|Enable this if this is the only backend or is the master backend server. If enabled, all frontend and non-master backend machines will connect to this server. To change to a new master backend, run setup on that server and select it as master backend.
+|Enable this on your master backend
+|-
+|Master Backend Name
+| align="center" |
+|Host name of Master Backend. This is set by selecting &quot;This server is the Master Backend&quot; on that server
+|You cannot update this directly. It is set when you select the prior check box.
+|-
+|}
+===Locale Settings===
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
 |-
 |TV format
 | align="center" |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.
+|Other choices include: ATSC, PAL, SECAM, PAL-NC, PAL-M, PAL-N, NTSC-JP. Be sure to set to the proper format for your region.
 |-
 |VBI format
-| align="center" |None
+| align="center" |NTSC Closed Caption
-|VBI stands for Vertical Blanking Interrupt. VBI is used to carry Teletext and Closed Captioning data.
+|VBI stands for vertical blanking interval, the time between tracing the last line on the display and returning to the first, when the CRT's electron beam is turned off (blanked). The 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,
+|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, NTSC closed caption
 |-
 |Channel frequency table
-| align="center" |us-cable
+| align="center" |us-bcast
 |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.
+|Other choices include: us-bcast, us-cable, us-cable-hrc, us-cable-irc, japan-bcast, japan-cable, europe-west, europe-east, italy, newzealand, australia, ireland, france, china-bcast, southafrica, argentina, australia-optus, singapore, malaysia, israel-hot-matav, try-all.
-|-
-|Time offset for XMLTV listings
-| align="center" | 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=====
+===Miscellaneous Settings===
-{| border="1" cellspacing="0" cellpadding="5" align="center"
+{| class="wikitable" style="width: 100%;"
-|colspan="4" align="center" style="background: #efefef;" | '''Miscellaneous Settings'''
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
 |-
-! |Setting
+| colspan="4" align="left" | '''File Management Settings'''
-! |Default Value
-! |Settings Page's Description
-! |Additional Comments
 |-
 |Master Backend Override
 | align="center" | 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
+|For a single backend setup, leave this checked. This means that all files will stream from the master backend. It also means all files must be available on the master backend. If you have slave backends either uncheck this or if you check it make sure that all storage directories are mounted on the master backend.
 |-
 |Follow Symbolic links when deleting files
-| align="center" | Not checked
+| align="center" | 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
+|In a normal recording setup mythtv does not use symbolic links so this will have no effect. Normally you should leave this unchecked unless you have your own file manipulation going on outside of MythTV.
 |-
 |Delete Files Slowly
-| align="center" | Not checked
+| align="center" | 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.
+|Select this if using ext3 file system for recordings. It is not needed with ext4.
 |-
 |HD Ringerbuffer size (kb)
 | align="center" | 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 HD device ring buffer allows the backend to weather moments of stress.  the larger the ring buffer, 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.
+|The default setting should be used in normal conditions. Modern machines have gigabytes of memory so this can safely be increased if you are experiencing pauses during playback.
+|-
+|Storage Group disk scheduler
+|Balanced free space
+|This setting controls how the Storage Group scheduling code will balance new recordings across directories. &apos;Balanced Free Space&apos; is the recommended method for most users.
+|See [[Setup Storage Directories#Storage Group Disk Scheduler]] for full details.
+|-
+| colspan="4" align="left" | '''UPnP Server Settings'''
+|-
+|Video Content to show a WMP Client
+| align="center" | Recordings
+| Which tree to show a Windows Media Player client when it requests a list of videos.
+| MythTV supports watching of recordings or Videos with Windows Media Player and other applications. This determines whether they can see recordings or Videos.
+|-
+| colspan="4" align="left" | '''Other Settings'''
 |-
 |Miscellaneous Status Application
 | align="center" | blank
-| External Application or script that outputs extra information for inclusion in the backend status page.  See contrib/misc_status_info/README
+| External application or script that outputs extra information for inclusion in the backend status page. See <nowiki> http://www.mythtv.org/wiki/Miscellaneous_Status_Information </nowiki>
-|no comments.
+| See [[Miscellaneous Status Information]]
+|-
+|Disable Automatic Database Backup
+| align="center" | Not Checked
+| If enabled, MythTV will not backup the database before upgrades. You should therefore have your own database backup strategy in place.
+| It is recommended to leave this unchecked.
 |-
 |Disable Firewire Reset
-| align="center" | Unchecked
+| align="center" | Not Checked
 | 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.
+| Unfortunately Firewire recording is somewhat unreliable, whether this option is selected or not.
 |-
 |}
-=====Shutdown/Wakeup Options=====
+===EIT Scanner Options===
-{| border="1" cellspacing="0" cellpadding="5" align="center"
+{| class="wikitable" style="width: 100%;"
-|colspan="4" align="center" style="background: #efefef;" | '''Shutdown/Wakeup Options'''
 |-
-! |Setting
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
-! |Default Value
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
-! |Settings Page's Description
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
-! |Additional Comments
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
+|EIT transport timeout (mins)
+| align="center" |5
+|Maximum time to spend waiting (in minutes) for listings data on one digital TV channel before checking for new listings data on the next channel.
+|For information on using EIT to obtain program listings see [[EIT]].
+|-
+|Backend idle before EIT crawl (secs)
+| align="center" |60
+|The minimum number of seconds after a recorder becomes idle to wait before MythTV begins collecting EIT listings data.
+|For information on using EIT to obtain program listings see [[EIT]].
+|-
+|}
+===Shutdown/Wakeup Options===
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
 |-
 |Startup command
-| align="center |(empty)
+| align="center" | blank
 |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.
@@ Line 205: / Line 330: @@
 | align="center" |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.
+|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.
 |-
 |Idle timeout (secs)
 | align="center" |0
-|The amount of time the master backend idles before it shuts down all backends. Set to 0 to disable auto shutdown.
+|The number of seconds the master backend idles before it shuts down all other backends. Set to 0 to disable automatic 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.
+|If you want the backend to shut down when idle you must set this value as non zero.
 |-
 |Max. wait for recording (min)
@@ Line 217: / Line 342: @@
 |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)
+|Startup before recording (secs)
 | align="center" |120
-|The amount of time the master backend will be woken up before a recording starts.
+|The number of seconds 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.
+|this is the amount of time you are allowing for the backends to boot up and be ready for recording. 120 seconds is cutting it a bit fine. 300 secodns would eb a good choice, and maybe more if you have slave backends that also do recording.
 |-
 |Wakeup time format
 | align="center" |hh:mm yyyy-MM-dd
-|The format of the time string passed to the 'setWakeuptime Command' as $time. See QT::QDateTime.toString() for details.
+|The format of the time string passed to the &apos;Command to set wakeup time&apos; as $time. See QT::QDateTime.toString() for details. Set to &apos;time_t&apos; for seconds since epoch.
-|Set this parameter to be the same as that expected by the BIOS clock.
+|Set this parameter to be the same as that expected by the Command to set Wakeup Time below.
 |-
 |Command to set Wakeup Time
-| align="center" |Blank
+| align="center" |blank
-|The command used to set the time (passed as $time) to wake up the master backend.
+|The command used to set the wakeup time (passed as $time) for the Master Backend
-|This command needs to call an external script. Here is an example command '
+|If you have set an idle timeout, the backend will shut down. You must set up a script to set a wakeup time and give the script name here. See [[ACPI Wakeup]] for details on setting a wakeup 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
-<pre>
- sudo echo $1 > /home/mythtv/myth.time
- sudo echo $1 > /proc/acpi/alarm
-</pre>
 |-
 |Server halt command
 | align="center" |sudo /sbin/halt -p
 |The command used to halt the backends.
-|This command needs to call an external script. Here is an example command '
+|This command needs to call an external script. If you are using sudo here you will need to set up permission for the backend to run the command without a password.
-  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
 | align="center" |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.
+|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 a script here that checks stuff before it shuts down. Also if you are logged into the machine doing some work you do not want it to shut 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
+===Backend Wakeup settings===
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
+| colspan="4" align="left" | '''Master Backend'''
-after setting up ssh authentication without passwords from master backend to slave backend.
+These settings are only used when your database is running but your master backend is not. If the master backend and database automatically start with the backend machine, then configure the datbase wakeup in the frontend settings and leave this out. If the master database is on a separate server, configure the wakeup settings for the database in the frontend and configure the master backend wakeup settings here.
+|-
+|Delay between wake attempts (secs)
+| align="center" | 0
+|Length of time the frontend waits between tries to wake up the master backend. This should be the time your master backend needs to startup. Set to 0 to disable.
+|Set a value to enable the wake up, and allow enough time for the backend to start.
+|-
+|Wake Attempts
+| align="center" | 5
+|Number of times the frontend will try to wake up the master backend.
+|Normally only 1 attempt would be required. In case you happen to invoke a remote frontend while the backend is in the process of shutting down, it may not work and you may need more than 1 attempt.
+|-
+|Wake Command
+| align="center" | blank
+|The command used to wake up your master backend server (e.g. sudo /etc/init.d/mythtv-backend restart).
+|The example command may be misleading. This is a command that will be run on a frontend to wake a master backend. It should normally invoke a wake-on-lan command.
+|-
+| colspan="4" align="left" | '''Slave Backends'''
+|-
+|Sleep Command
+| align="center" | blank
+|The command used to put this slave to sleep. If set, the master backend will use this command to put this slave to sleep when it is not needed for recording.
+|Set this while running setup on the slave backend machine.
+|-
+|Wake Command
+| align="center" | blank
+|The command used to wake up this slave from sleep. This setting is not used on the master backend.
+|Set this while running setup on the slave backend machine.
 |-
 |}
+===Backend Control===
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
+| colspan="4" align="left" | '''Backend Control'''
-=====WakeOnLan settings=====
+Settings here are run on each backend, master or slave.
-MasterBackend
+|-
+|Backend stop command
+| align="center" | killall mythbackend
+|The command used to stop the backend when running on the master backend server (e.g. sudo /etc/init.d/mythtv-backend stop)
+|This command is used to stop the backend when setup is run and you choose to close the backend. '''Note:''' when you use the Ubuntu or Mythbuntu package there is a script that invokes backend setup and it does not use this setting for stopping the backend.
+|-
+|Backend start command
+| align="center" | mythbackend
+|The command used to start the backend when running on the master backend server (e.g. sudo /etc/init.d/mythtv-backend start).
+|This command is used to restart the backend when setup is closed and you had selected for setup to close the backend. '''Note:''' Like the stop command above this is not used when you installed the Mythbuntu or Ubuntu package.
+|-
+|}
+===Job Queue (Backend-Specific)===
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
+| colspan="4" align="left" | Settings here are run on each backend, master or slave.
+|-
+|Maximum simultaneous jobs on this backend
+| align="center" | 1
+|The Job Queue will be limited to running this many simultaneous jobs on this backend.
+|Adjust this according to the power of this backend machine.
+|-
+|Job Queue check frequency (secs)
+| align="center" | 60
+|When looking for new jobs to process, the Job Queue will wait this many seconds between checks.
+|There is probably no reason to change this.
+|-
+|Job Queue start time
+| align="center" | 0:00
+|This setting controls the start of the Job Queue time window, which determines when new jobs will be started.
+|You can limit the time periods when jobs will run.
+|-
+|CPU usage
+| align="center" | Low
+|This setting controls approximately how much CPU jobs in the queue may consume. On &apos;High&apos;, all available CPU time may be used, which could cause problems on slower systems.
+|You can limit the time periods when jobs will run.
+|-
+|Allow metadata lookup jobs
+| align="center" | Checked
+|If enabled, allow jobs of this type to run on this backend.
+|
+|-
+|Allow commercial-detection jobs
+| align="center" | Checked
+|If enabled, allow jobs of this type to run on this backend.
+|
+|-
+|Allow transcoding jobs
+| align="center" | Checked
+|If enabled, allow jobs of this type to run on this backend.
+|
+|-
+|Allow User Job #1 jobs
+| align="center" | Not Checked
+|If enabled, allow jobs of this type to run on this backend.
+|User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
+|-
+|Allow User Job #2 jobs
+| align="center" | Not Checked
+|If enabled, allow jobs of this type to run on this backend.
+|User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
+|-
+|Allow User Job #3 jobs
+| align="center" | Not Checked
+|If enabled, allow jobs of this type to run on this backend.
+|User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
+|-
+|Allow User Job #4 jobs
+| align="center" | Not Checked
+|If enabled, allow jobs of this type to run on this backend.
+|User jobs are configured on the next page. You can create up to 4 jobs to run any command you want upon completion of the system making a recording.
+|-
+|}
-Reconnect wait time (secs):
+===Job Queue (Global)===
+{| class="wikitable" style="width: 100%;"
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
+|Run Jobs only on original recording backend
+| align="center" | Not Checked
+|If enabled, jobs in the queue will be required to run on the backend that made the original recording.
+|If you leave this unchecked, you have to make sure that all recording directories are available on all backends, via NFS or another mechanism.
+|-
+|Start auto-commercial-detection jobs when the recording starts
+| align="center" | Not Checked
+|If enabled, and Auto Commercial Detection is ON for a recording, the flagging job will be started as soon as the recording starts. NOT recommended on underpowered systems.
+|
+|-
+|Commercial-detection command
+| align="center" |mythcommflag
+|The program used to detect commercials in a recording. The default is &apos;mythcommflag&apos; if this setting is empty.
+| See [[User Jobs]] for arguments that can be used. <br>
+Equivalent default command: '''mythcommflag -j %JOBID% -V %VERBOSELEVEL%'''
+|-
+|Transcoder command
+| align="center" |mythtranscode
+|The program used to transcode recordings. The Defaults is 'mythtranscode' if this setting is empty.
+| See [[User Jobs]] for arguments that can be used. <br>
+Equivalent default command: '''mythtranscode -j %JOBID% -V %VERBOSELEVEL% -p %TRANSPROFILE% [-l]''' <br>
+('-l' is passed only if cutlists are to be used in transcoding)
+|-
+|RunRun transcode jobs before auto commercial detection
+| align="center" |Not Checked
+|If enabled, and if both auto-transcode and commercial detection are turned ON for a recording, transcoding will run first; otherwise, commercial detection runs first.
+|
+|-
+|Save original files after transcoding (globally)
+| align="center" |Not Checked
+|If enabled and the transcoder is active, the original files will be renamed to .old once the transcoding is complete.
+|
+|-
+|}
-Count of reconnect tries:
+===Job Queue (Job Commands)===
+{| class="wikitable" style="width: 100%;"
-Wake Command
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
-Wake command for slaves:
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
-=====Job Queue (Host-Specific)=====
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
-Maximum simultaneous jobs on this backend:
+|-
+|User Job #1 description
-Run Jobs only on original recording host
+| align="center" | User Job #1
+|The description for this User Job.
-Job Queue Check frequency (in seconds)
+|If you create a user job, change this to a name for the user job. This name is shown in the frontend and other places when referring to the job.
+|-
-CPU Usage
+|User Job #1 command
+| align="center" | blank
-Allow Commercial Detection jobs
+|The command to run whenever this User Job number is scheduled.
+|This is typically a script you have created to do some task after a recording is complete.
-Allow User Job #1 jobs
+|-
+|User Job #n description
-Allow User Job #2 jobs
+| align="center" | User Job #n
+|The description for this User Job.
-Allow User Job #3 jobs
+|There are prompts for 4 user jobs, 1 - 4.
+|-
-Allow User Job #4 jobs
+|User Job #n command
+| align="center" | blank
+|The command to run whenever this User Job number is scheduled.
-=====Job Queue (Global)=====
+|There are prompts for 4 user jobs, 1 - 4.
-Run Jobs only on original recording backend.
+|-
+|}
-Start Auto-commercial Flagging jobs when the recording starts.
+===Program Schedule Downloading Options===
+{| class="wikitable" style="width: 100%;"
-Commercial Flagger command:
+|-
+|style="width: 20%; background-color: #E6E6FF;" align="center"|'''Setting'''
-Transcoder command:
+|style="width: 10%; background-color: #E6E6FF;" align="center"|'''Default Value'''
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Settings Page's Description'''
-Run Transcode Jobs before Auto-Commericial Flagging
+|style="width: 35%; background-color: #E6E6FF;" align="center"|'''Additional Comments'''
+|-
-Save origional files after transcoding (globally)
+|Automatically update program listings
+| align="center" | Checked
-=====Job Queue (Job Commands)=====
+|If enabled, the guide data program will be run automatically.
-User Job #1 Description:
+|If you want the backend to invoke the guide data program once a day, enable this. Many people use a cron script or other method of running it, in which case this should be unchecked.
+|-
-User Job #1 Command:
+|Guide data program
+| align="center" | mythfilldatabase
-User Job #2 Description:
+|Use &apos;mythfilldatabase&apos; or the name of a custom script that will populate the program guide info for all your video sources.
+|This program will run under the same user id as the backend. If you are using xmltv for your guide data you will have to make sure that the data in the home directory that set up xmltv is available to mythfilldatabase.
-User Job #2 Command:
+|-
+|Guide data arguments
-User Job #3 Description:
+| align="center" | blank
+|Any arguments you want passed to the guide data program.
-User Job #3 Command:
+|See [[mythfilldatabase]] or run "mythfilldatabase -h" for details of valid arguments for mythfilldatabase. When using schedules direct, we recommend using the --dd-grab-all argument.
+|-
-User Job #4 Description:
+|Guide data program execution start
+| align="center" | 0
-User Job #4 Command:
+|This setting and the following one define a time period when the guide data program is allowed to run. For example, setting start to 11 and end to 13 would mean that the program would only run between 11:00 AM and 1:59 PM.
+|
-==Capture Cards==
+|-
+|Guide data program execution end
-===General configuration===
+| align="center" | 23
-{{Incomplete}}
+|This setting and the preceding one define a time period when the guide data program is allowed to run. For example, setting start to 11 and end to 13 would mean that the program would only run between 11:00 AM and 1:59 PM.
---[[User:Mitchell2345|Mitchell]] 03:59, 19 March 2008 (UTC)In-progress
+|
-====Video sources====
+|-
---[[User:Mitchell2345|Mitchell]] 03:59, 19 March 2008 (UTC)In-progress
+|Run guide data program at time suggested by the grabber.
-====Input Connections====
+| align="center" | Checked
---[[User:Mitchell2345|Mitchell]] 03:59, 19 March 2008 (UTC)In-progress
+|If enabled, allow a DataDirect guide data provider to specify the next download time in order to distribute load on their servers. Guide data program execution start/end times are also ignored.
-====Channel Editor====
+|Currently Schedules Direct always suggests the next time as 24 hours later, so this is not very useful.
---[[User:Mitchell2345|Mitchell]] 03:59, 19 March 2008 (UTC)In-progress
+|-
-====Storage Groups====
+|}
---[[User:Mitchell2345|Mitchell]] 03:59, 19 March 2008 (UTC)In-progress
-===Satellite tunercard (DVB-S) ===
-In this section we will explain how to work with the more advance configuration options for your satelite capture cards.
-Configuring your satellite setup(DVB-S) generally involves more configuration options than cable(DVB-C), teresterial(DVB-T) or analogue cards. In this section we will explain how to configure your satellite setup and satellite tuners cards.
-====Hardware setup====
-todo about lnb's, multiple tuners,etc..
-====Video sources====
-====Input Connections====
-====Channel Editor====
-====Storage Groups====
-====Diseqc configurating====
-====CI and CAM configuration (for pay television====
-====CAM extenders======
-====Troubleshooting====
-==Starting mythbackend==
-Once configuration is done you can test to see if the mythbackend process is running correctly by starting it in a Terminal window:
- > /usr/bin/mythbackend
-Watch out for any error messages.
+== Other Setup Pages ==
-You may also find it useful to read about [[Mythwelcome]] and [[ACPI Wakeup]]
+The rest of the setup pages are described in the next chapter, [[User Manual:MythTV structure]].
-{{Navigate|User Manual:Setting Up|User Manual:Index|User Manual:Detailed configuration Frontend}}
+[[Category:Configuring MythTV|1100]]