Setup General
| Previous | Up | Next |
|---|---|---|
 User Manual:Setting Up |
 User Manual:Index |
User Manual:Detailed configuration Frontend 
|
Backend
MythTV Detailed Backend Configuration v. 0.18.1. (Incomplete)
Contents
MythTV Backend
The backend process (mythbackend) is the portion of the system that handles the Video capture cards as well as Scheduling Recordings on those cards, Commercial Flagging, and transcoding. The backend process interacts with the Database primarily.
As with the MythFrontend, there can be multiple backends. One backend process is designated as the master backend. This is usually the first backend installed on a system. This backend is responsible for coordinating the activities of the other backends known as slaves. This is especially true for scheduling as the master backend will determine the best distribution of programs across all available tuners. Each backend can have any number of tuners, including zero. As of 0.16, Commercial Flagging can be distributed across different backends, thereby spreading the load of that process.
There is no requirement for direct user interaction with the backend. The backend can use local HardWare/File Storage or have it mounted from another system. If remotely mounted, network performance should be considered as there will be considerable traffic on the network as recordings are stored and retreived by the backend process.
Communications Protocol
The backend and frontend communicate using their own Myth Protocol. The developer of Win Myth, a windows frontend to MythTV for playing recordings on Windows, has documented his workings on the procotol here. Work on defining the Myth Protocol is also be performed on this Wiki.
Backend Configuration
The MythTV Backend configuration has two main objectives
- Tell MythTV what TV Capture/Tuner cards to use
- Populate the Myth Database with information about channels and tuning information
There are additional items that can be configured, but without successfully achieving the above two steps you will not be able to get Live TV.
Running mythtv-setup
Configure the Myth backend like so
> mythtv-setup
The system will now prompt to see if you want to keep the current TV card settings as well as the channel information.
Once configuration is done you can test to see if the mythbackend process is running correctly by starting it in a Terminal window:
> mythbackend
Watch out for any error messages.
Backend Reference
| Host Address Backend Setup | |||
| Setting | Default Value | Settings Page's Description | Additional Comments |
|---|---|---|---|
| IP address for mythtv | 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. | This is the meat of the subject |
| Port the server runs on | 6543 | Unless you’ve got a good reason to, don’t change this. | This is the meat of the subject |
| Port the server shows status on | 6544 | Port which the server will listen to for HTTP requests. Currently, it shows a little status information. | This is the meat of the subject |
| Master Server IP address | 127.0.0.1 | The IP address of the master backend server. All frontend and non-master backend machines will connect to this server. If you only have one backend, this should be the same IP address as above. | This is the meat of the subject |
| Port the master server runs on | 6543 | Port which the server will listen to for HTTP requests. Currently, it shows a little status information. | This is the meat of the subject |
| Host-Specific Backend Setup | |||
| Directory to hold recordings | /mnt/store/ | All recordings get stored in this directory. | Be sure this directory exists and that proper permissions are set for the mythtv user. If the directory does not exist or is inaccessible, the backend will not start. |
| Directory to hold the Live-TV buffers | PUT IN THE DEFAULT HERE | All Live-TV buffers will get stored in this directory. These buffers are used to allow you to pause, fast forward and rewind through live TV. | Be sure this directory exists and that proper permissions are set for the mythtv user. If the directory does not exist or is inaccessible, the backend will not start. |
| Live TV Buffer (GB) | PUT IN THE DEFAULT HERE | How large the live TV buffer is allowed to grow. | This is the meat of the subject |
| Minimum free Live TV Buffer | PUT IN THE DEFAULT HERE | How full the live TV buffer is allowed to grow before forcing an unpause. | This is the meat of the subject |
| Save original files after transcoding | Not checked | When set and the transcoder is active, the original nuv files will be renamed to nuv.old once the transcoding is complete. | This is the meat of the subject |
| Global Backend Setup | |||
| TV format | NTSC | The standard to use for viewing TV. | This is the meat of the subject |
| VBI format | None | VBI stands for Vertical Blanking Interrupt. VBI is used to carry Teletext and Closed Captioning data. | This is the meat of the subject |
| Channel frequency table | us-cable | Select the appropriate frequency table for your system. If you have an antenna, use a “-bcast” frequency. | This is the meat of the subject |
| Time offset for XMLTV listings | None | If your local timezone does not match the timezone returned by XMLTV, use this setting to have mythfilldatabase adjust the program start and end times. None disables this feature, Auto automatically detects your local timezone. | This is the meat of the subject |
| Master Backend Override | Checked | If enabled, the master backend will stream and delete files if it finds them in the video directory. Useful if you are using a central storage location, like a NFS share, and your slave backend isn’t running. | This is the meat of the subject |
| Follow Symbolic links when deleting files | Not checked | This will cause Myth to follow symlinks when recordings and related files are deleted, instead of deleting the symlink and leaving the actual file. | This is the meat of the subject |
| Shutdown/Wakeup Options | |||
| Block shutdown before client connected | Checked | If set, the automatic shutdown routine will be disabled until a client connects. | This is the meat of the subject |
| Idle timeout (secs) | 0 | The amount of time the master backend idles before it shuts down all backends. Set to 0 to disable auto shutdown. | This is the meat of the subject |
| 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. | This is the meat of the subject |
| Startup before rec. (secs) | 120 | The amount of time the master backend will be woken up before a recording starts. | This is the meat of the subject |
| Wakeup time format | hh:mm yyyy-MM-dd | Copy the description on the page Here | This is the meat of the subject |
| Set wakeuptime command | Blank | The command used to set the time (passed as $time) to wake up the masterbackend. | This is the meat of the subject |
| Server halt command | sudo /sbin/halt -p | The command used to halt the backends. | This is the meat of the subject |
| Pre Shutdown check-command | Blank | A command executed before the backend would shutdown. The return value determines if the backend can shutdown. 0 - yes, 1 - restart idling, 2 - reset the backend to wait for a frontend. | This is the meat of the subject |
WakeOnLan settings
MasterBackend
Reconnect wait time (secs):
Count of reconnect tries:
Wake Command
Wake command for slaves:
Job Queue (Host-Specific)
Maximum simultaneous jobs on this backend:
Run Jobs only on original recording host
Job Queue Check frequency (in seconds)
CPU Usage
Allow Commercial Detection jobs
Allow User Job #1 jobs
Allow User Job #2 jobs
Allow User Job #3 jobs
Allow User Job #4 jobs
Job Queue (Job Commands)
User Job #1 Description:
User Job #1 Command:
User Job #2 Description:
User Job #2 Command:
User Job #3 Description:
User Job #3 Command:
User Job #4 Description:
User Job #4 Command:
