MythTV-HOWTO - 0.26
- 1 First things first
- 2 Introduction
- 3 Checking prerequisites
- 3.1 Hardware
- 3.1.1 CPU Type and Speed
- 3.1.2 Software / CPU-based encoding
- 3.1.3 Hardware based encoding
- 3.1.4 Memory
- 3.1.5 Hard Disk(s)
- 3.1.6 Filesystems
- 3.1.7 Video Capture Device
- 3.1.8 Playback of HDTV using CPU
- 3.1.9 Playback of HDTV using VDPAU
- 3.2 Sound card
- 3.3 Video Display Card
- 3.4 Software
- 3.1 Hardware
- 4 System Configuration Requirements for Compiling MythTV
- 5 Downloading and compiling
- 6 MySQL
- 7 Configuring Sound
- 8 Setting up a remote control
- 9 Configuring MythTV
- 9.1 Configuring the Master backend system
- 9.2 Post-configuration
- 9.3 Configuring a non-master backend
- 9.4 Configuring and running mythfilldatabase
- 9.5 Grabbing channel icons for Schedules Direct users
- 10 Configuring mythfrontend
- 11 Using MythTV
- 11.1 Keyboard commands
- 11.1.1 mythfrontend
- 11.1.2 Watching TV or a recording
- 11.1.3 Watching TV only
- 11.1.4 LiveTV Browse Mode
- 11.1.5 Playback Recording Zoom Mode
- 11.1.6 If you have two or more tuner cards
- 11.1.7 Watching a recording only
- 11.1.8 EPG
- 11.1.9 Setting Program or Channel Recording Priorities
- 11.1.10 Viewing Scheduled Recordings/Resolving Conflicts
- 11.1.11 Viewing Search Listings
- 11.1.12 Recording Profiles Setup Screen
- 11.1.13 Recording Groups
- 11.1.14 Watch Recordings Screen
- 11.1.15 Remote Controls
- 11.2 Using themes with MythTV
- 11.3 Adding support for an external tuner
- 11.4 Using Shutdown/Wakeup
- 11.5 Controlling the mythfrontend via telnet
- 11.1 Keyboard commands
- 12 Scheduling Recordings
- 12.1 Record Types
- 12.2 Scheduling Options
- 12.3 Storage Options
- 12.4 Post Recording Processing
- 12.5 Advanced Recording Options
- 12.6 Scheduling with more than one Input
- 13 MythPlugins
- 13.1 MythWeb
- 13.2 MythGallery
- 13.3 MythGame
- 13.4 MythMusic
- 13.5 MythWeather
- 13.6 MythNews
- 14 Troubleshooting
- 14.1 Compiling
- 14.2 Debugging
- 14.3 Installing
- 14.4 Using
- 14.5 Miscellaneous
- 14.5.1 mythfilldatabase failing
- 14.5.2 Frontend appears to be slow at jumping / seeking
- 14.5.3 On-screen Display shows incorrect program length
- 14.5.4 Troubleshooting audio
- 14.5.5 Mythbackend reports that your card is not reporting full duplex capabilities
- 14.5.6 The mythbackend program told me to look at this section
- 14.5.7 My remote doesn't work / works sometimes and not others / "ghost" keypresses
- 14.5.8 Where's "canada-cable"?
- 14.5.9 Channels are off by one
- 14.5.10 Mythweb is showing a db_open error when I connect to it
- 14.5.11 Mouse pointer disappears when placed over the MythTV windows
- 14.5.12 What does "strange error flushing buffer" mean on the console?
- 14.5.13 Can't change the channel when watching Live TV
- 14.5.14 Screen goes black when you try to play something
- 14.5.15 Computer is loading a media player application when you insert a CD or DVD
- 15 Miscellaneous
- 15.1 I'd like to watch the files without using MythTV / I'd like to convert the files to some other format
- 15.2 Using a different window manager
- 15.3 What capture resolution should I use? How does video work?
- 15.4 MythTV GUI and X Display Sizes
- 15.5 Saving or restoring the database
- 15.6 btaudio
- 15.7 Removing unwanted channels
- 15.8 NFS
- 15.9 Automatically starting mythfrontend at system boot time
- 15.10 Advanced Backend Configurations
- 15.11 Using the transcoder
- 15.12 Changing your hostname
- 15.13 Can I run MythTV on my TiVo?
- 15.14 Can I run MythTV on my ReplayTV?
- 15.15 Can a wireless connection be used between the frontend and the backend?
- 15.16 How can I burn shows that I have recorded to a DVD?
- 15.17 What do the icons on the Watch Recordings screen mean?
- 15.18 What do the letters mean when I change channels?
- 15.19 What is the difference between the various Hauppauge PVR models?
- 15.20 Changing channels on an external Set Top Box
- 15.21 Configuring one machine to flag all commercials
- 16 Example Configurations.
- 17 Caching support for Schedules Direct
First things first
NOTE: Please note that this page is not meant to provide personalized support for installing or running MythTV. If you are having issues installing or running MythTV you should examine the mailing list archives, or post your question to the MythTV-users mailing list.
What is MythTV
MythTV is a GPL licensed suite of programs that allow you to build the mythical home media convergence box on your own using Open Source software and operating systems. MythTV is known to work on Linux and Mac OS X (PowerPC and Intel). A Windows cross-compiled version is under development.
MythTV has a number of capabilities. The television portion allows you to do the following:
- You may pause, fast-forward and rewind live Television.
- You may install multiple video capture cards to record more than one program at a time.
- You can have multiple servers (called "backends"), each with multiple capture cards in them. All scheduling is performed by the Master backend, which arbitrates which recording will be performed by each device. All recording requests are managed by the Master backend, so you can schedule a recording from any client.
- You can have multiple clients (called "frontends" in MythTV parlance), each with a common view of all available programs. Any client can watch any program that was recorded by any of the servers, assuming that they have the hardware capabilities to view the content; a low-powered frontend will not be able to watch HDTV, for example. Clients can be diskless and controlled entirely by a remote control.
- You may use any combination of standard analog capture card, MPEG-2, MJPEG, DVB, HDTV, USB and firewire capture devices. With appropriate hardware, MythTV can control set top boxes, often found in digital cable and satellite TV systems.
- Program Guide Data in North America is downloaded from schedulesdirect.org, a non-profit organization which has licensed data from Tribune Media Services. This service provides almost two weeks of scheduling information. Program Guide Data in other countries is obtained using XMLTV. MythTV uses this information to create a schedule that maximizes the number of programs that can be recorded if you don't have enough tuners.
- MythTV implements a UPNP server, so a UPNP client should automatically see content from your MythTV system.
Other modules in MythTV include:
- MythArchive, a tool to create DVDs
- MythBrowser, a web browser
- MythGallery, a picture-viewing application
- MythGame, an application for running games installed on the system
- MythMusic, a music playing / ripping application which supports MP3 and FLAC
- MythNetvision, an application for playing Internet streaming video
- MythNews, a RSS news grabber
- MythWeather, and application for showing weather information
- MythWeb, which allows you to control your MythTV system using a web browser. With MythWeb, you can schedule and delete recordings and more. With proper security, you may even schedule a program over the Internet and have it immediately acted on by the Master backend.
Custom mini-distributions are available to make it easier to install MythTV. A mini-distribution removes many of the "general purpose" workstation / server software packages that may be installed by default if you use one of the big-name OS packages.
See http://mysettopbox.tv if you'd like to install a custom version of Arch Linux optimized for MythTV.
See http://www.minimyth.org for a small MythTV distribution which can be booted over a network.
See http://wilsonet.com/mythtv/ for instructions tailored to RedHat's Fedora Core distribution.
See http://www.mythbuntu.org/ for a distribution using a customized Ubuntu.
See http://www.mythdora.com/ for a distribution using a customized Fedora Core.
Upgrading from previous versions
The upgrade from previous versions should be transparent. Any changes to the database structure should be applied automatically.
It is strongly recommended that you back up your database before installing a new version of MythTV.
How to obtain this document / PDF versions of this document
This HOWTO document is maintained within the MythTV wiki: http://www.mythtv.org/wiki/MythTV-HOWTO . While the wiki page is protected from editing, we do encourage users to submit corrections or discussion to the "discussion" page (available by clicking the "discussion" tab at the top of the wiki page).
The MythTV HOWTO was originally written by Robert Kulagowski.
This document is available as a PDF at http://www.mythtv.org/docs/mythtv-HOWTO.pdf
This HOWTO is for MythTV v0.26
Release notes for this version may be found in the MythTV Wiki at http://www.mythtv.org/wiki/Release_Notes_-_0.26
Books about MythTV
If you would like to purchase a book specifically about MythTV:
- Hacking MythTV, ISBN 978-0470037874 by Wilson, Tittel, Wright and Korelc
- Practical MythTV: Building a PVR and Media Center PC, ISBN 978-1590597798 by Smith and Still
Note that these books cover earlier versions of MythTV.
The following conventions are used throughout this document.
boldface - used for program names.
typewriter - used for program paths.
emphasis - Pay attention here.
Mailing lists / getting help
It's recommended that you join the user list at http://www.mythtv.org/mailman/listinfo/mythtv-users
The developer list is at http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
- Please keep the developer list strictly for development-related issues.
Searchable archives for the lists are available at http://www.gossamer-threads.com/lists/mythtv/
There are two IRC channels dedicated to MythTV which can be found on irc.freenode.net
The mythtv channel is where the developers discuss code. It is not a user-support channel. Please don't ask non-development related questions there.
If you feel you need to contribute to a bug database, use the MythTV bug ticketing system at http://code.mythtv.org/trac
Good entries will contain the following:
- Qt version
- Linux distribution
- gcc version
- the last entry in config.log to detail how you compiled
- MythTV version numbers (e.g.from mythfrontend --version)
- How you are able to reproduce the bug
See the instructions on how to debug in Section 22.
The bug database is not a chat room, so restrict your entries to what is relevant. It's also not a repository of feature requests; a feature request without an accompanying patch file to implement that feature will be quickly closed. There is a feature wishlist on the wiki at http://www.mythtv.org/wiki/Feature_Wishlist There is no guarantee that anything on the wishlist will ever get code written to implement it.
If a developer closes out your bug, it's likely you didn't provide enough information. Don't re-open a bug without providing additional information.
This HOWTO document will focus on manually building MythTV in a North American environment. If you have installation instructions for a different region or Linux distribution, please send them to the author so that it can be included in other versions of this document.
You must ensure that any firewalls (either hardware, or a software firewall installed by your distribution) will not block access to the ports that will be used by the MythTV clients and servers on the "inside" LAN. The ports for MySQL (TCP port 3306) and mythbackend (TCP ports 6543 and 6544) must be open. It is strongly recommended that you do not expose the MythTV and MySQL ports to the Internet or your "Outside" LAN.
Hardware selection is a complex topic, one this HOWTO will only discuss briefly and in general terms. The following subsections offer some general guidance but stop short of offering specific recommendations.
For a good MythTV experience, you must understand that MythTV exercises your hardware more than a typical desktop. Encoder cards generate DMA across the PCI bus. The CPU is busy encoding / decoding video. Hard drives are constantly reading and writing data. Building a MythTV system on older / "spare" hardware may be an exercise in frustration and can waste many hours of valuable time.
If you have specific questions about the suitability of specific hardware choices, you can consult the archives of the mythtv-users mailing list at http://www.gossamer-threads.com/lists/mythtv/ or post a question to the list.
CPU Type and Speed
Selection of CPU type and speed is one of the trickiest elements of hardware selection, mainly because there are so many tradeoffs which can be made. For example, if you have plenty of CPU, you can use higher bitrates or capture sizes, etc.
Software / CPU-based encoding
MythTV has two modes of operation for capturing video. First, it can function as a software video encoder, which means that it can use a fairly generic "dumb" video capture card to get frames of video, encodes them using the CPU on your motherboard and writes them to disk. High-end video capture cards and devices like the TiVo and ReplayTV have dedicated encoder chips which use specialized hardware to convert the video stream to the MPEG-2 format without using the motherboard CPU. The main CPU has the responsibility of running the Operating System and reading and writing the encoded frames to the disk. These tasks have fairly low CPU requirements compared to encoding video, which is why a device like a Series 1 TiVo can run with only 16MB of RAM and a 54MHz CPU.
That being said, due to the digital conversion in the United States, there are fewer sources of NTSC analog video, and cheap silicon has made it easier to include MPEG-2 encoders into hardware capture cards. In addition, the sale of "analog-only" cards has been severely curtailed in the United States, and one vendor received a fine for failing to include notification that their device was analog-only. http://hraunfoss.fcc.gov/edocs_public/attachmatch/DA-08-493A1.txt
There are many variables that go into the question: "How fast a CPU do I need to run MythTV"? Obviously, the faster your CPU, the better your experience will be with MythTV. If you are using the software MPEG-4 encoder and performing the "Watch TV" function, where the CPU is both encoding and decoding video simultaneously to allow Pause, Fast Forward and Rewind functions for live TV requires more CPU then just encoding or decoding. MythTV also supports multiple encoder cards in a single PC, thereby increasing the CPU requirements if you plan on simultaneously encoding multiple programs. As a general guideline, plan on 1GHz per encoder if you are doing software-based encoding, less if you are using a hardware-based encoder.
Here are a few data points:
- A PIII/733MHz system can encode one video stream using the MPEG-4 codec using 480x480 capture resolution. This does not allow for live TV watching, but does allow for encoding video and then watching it later.
- A developer states that his AMD1800+ system can almost encode two MPEG-4 video streams and watch one program simultaneously.
- A PIII/800MHz system with 512MB RAM can encode one video stream using the RTjpeg codec with 480x480 capture resolution and play it back simultaneously, thereby allowing live TV watching.
- A dual Celeron/450MHz is able to view a 480x480 MPEG-4/3300kbps file created on a different system with 30% CPU usage.
- A P4 2.4GHz machine can encode two 3300Kbps 480x480 MPEG-4 files and simultaneously serve content to a remote frontend.
Hardware based encoding
The second mode of operation is where MythTV is paired with a hardware-based video encoder, in which case MythTV will primarily be I/O bound. There are several examples of such devices, like the Hauppauge WinTV-PVR-150/250/350/500 series, the Hauppauge HD-PVR (H.264 High-Def capture using Component inputs), or the Silicon Dust HDHomerun. In this mode, because the video encoding is being done by a dedicated video processor (the Hauppauge encoders), or the device is simply writing the data to disk (the HDHR and other digital devices, such as DVB cards) the host CPU requirements are quite low. See the Video Capture Device section for details.
Primary development in MythTV has transitioned to supporting MPEG-2 capture devices, H.264 and HDTV, so if given the option, go with the hardware encoder or choose a ATSC capture device. Because of the transition to digital broadcast in the United States, most television stations are now digital-only. There are still analog stations in the U.S., but a majority are low-powered. Canada still has analog broadcasts.
Analog encoding or hardware MPEG-2 encoding may still be required if you are trying to capture standard definition video sources, such as set-top-boxes.
A MythTV host that is both a backend and a frontend and using software encoding with a single capture card should run adequately in 512MB of RAM. Additional RAM above 512MB will not necessarily increase performance, but may be useful if you are running multiple encoders.
Encoded video takes up a lot of hard disk space. The exact amount depends on the encoding scheme, the size of the raw images and the frames per second, but typical values for MythTV range from 700 megabytes/hour for MPEG-4, 2 GB/hour for MPEG-2 and RTjpeg and 7 GB/hour for ATSC HDTV.
Writing video to disk is sensitive to timing issues; RTjpeg requires less CPU with the tradeoff being larger files and needing to write to the disk faster. MPEG-4 requires more CPU, but the files are smaller. At the default resolution, MPEG-2 creates the largest files of all with almost no CPU impact.
MythTV creates large files, many in excess of 4GB. You must use a 64 or 128 bit filesystem. These will allow you to create large files. Filesystems known to have problems with large files are FAT (all versions), and ReiserFS (versions 3 and 4).
Because MythTV creates very large files, a filesystem that does well at deleting them is important. Numerous benchmarks show that XFS and JFS do very well at this task. You are strongly encouraged to consider one of these for your MythTV filesystem. JFS is the absolute best at deletion, so you may want to try it if XFS gives you problems. MythTV incorporates a "slow delete" feature, which progressively shrinks the file rather than attempting to delete it all at once, so if you're more comfortable with a filesystem such as ext3 (whose delete performance for large files isn't that good) you may use it rather than one of the known-good high-performance file systems. There are other ramifications to using XFS and JFS - neither offer the opportunity to shrink a filesystem; they may only be expanded. Ext4 is also an option if you prefer to stay with a "safer" file system.
Because of the size of the MythTV files, it may be useful to plan for future expansion right from the beginning. If your case and power supply have the capacity for additional hard drives, read through the Advanced Partition Formatting sections for some pointers.
Video Capture Device
In order to capture video, MythTV will need one or more video capture devices with Linux drivers. There are a number of classes of hardware available for capturing video.
This class of card is the simplest and is usually the cheapest. There is no on-board encoding of the analog video; hardware known as a Digital-Analog Converter (DAC) takes the video and presents it to the computer in an essentially raw digital form.
For a list of video capture cards known to work with Linux, please see /usr/src/linux/Documentation/video4linux/bttv for a partial listing; even if your specific card is not listed, it may be that the vendor is actually using a standard reference design and placing their own name on it. See the video4linux mailing list (http://listman.redhat.com/mailman/listinfo/video4linux-list) for more information and for specific hardware questions.
The most common inexpensive cards available use the Bt848, Bt878 or CX2388x series of video capture chips; examples are the "Hauppauge WinTV Go" card and the "AverTV Desktop PVR" card, both of which use the bttv kernel module.
After you have installed a suitable capture device, you can check that the kernel sees it with lspci. Look for an entry labeled "Multimedia video controller". To get more detailed information about the card, use lspci -v or lspci -vv. Ensure that your system is loading the bttv modules by typing:
# lsmod |grep bttv
You want to see the bttv module listed.
Hardware MPEG-2 encoders
While inexpensive video-capture cards simply capture raw frames, leaving encoding to software, some higher-end cards incorporate hardware-based encoding. Using either a G200 MJPEG encoder card, or a MPEG-2 encoder card supported by the IvyTV project http://ivtvdriver.org such as the Hauppauge PVR-150/250/350/500, Avermedia M179, Hauppauge "Freestyle" or Yuan M600 cards will allow you to use dedicated hardware encoders rather than your CPU. Using the on-board MPEG-2 encoder greatly reduces the CPU requirements for encoding.
NOTE: Motherboards with the Via chipset are notoriously bad with DMA and have caused numerous issues with ivtv, including hard locks. See the ivtv website http://ivtvdriver.org for the latest information on what works and what doesn't.
Here are some data points for encoding:
- A Celeron 450 uses 2% CPU for encoding a 480x480 16Mbps MPEG-2 stream.
Here are some data points for decoding:
- An Athlon 1800XP can decode a 720x480 8Mbps MPEG-2 file using 10% CPU
- An Athlon 1GHz can decode a 720x480 16Mbps MPEG-2 file using 30-50% CPU, can decode a 480x480 16Mbps MPEG-2 using 30% CPU and approximately 30% for Live TV at 416x480.
DVB capture cards
DVB is a video standard primarily found in Europe (where it comes in DVB-C, DVB-T and DVB-S and -S2 varieties for Cable, Terrestrial and Satellite) and is also used as the programming interface for HDTV capture cards in Linux. To see if your DVB card is supported, see the list of cards in the "Supported Hardware" section of the DVB Wiki at http://www.linuxtv.org/wiki/index.php/Main_Page for more information.
In the United States, you may use a card such as the TwinHan to obtain unencrypted Free-To-Air satellite channels. See http://www.lyngsat.com/ for the types of content which are available.
There are a number of HDTV cards with Linux drivers which are known to operate in the United States; a complete list of cards with DVB drivers can be found at http://www.linuxtv.org/ Some cards support capture of unencrypted digital cable TV (utilizing QAM64 or QAM256), others will only work with Over The Air signals captured with an antenna (with 8VSB).
None of the capture devices listed above perform any encoding; they merely allow your computer to save a copy of a HDTV stream which has already been converted to MPEG-2 at the broadcast facility.
Hauppauge HD PVR
Hauppuage makes a device called the HD PVR, which accepts component HDTV signals and TOSLINK / SPDIF audio and performs a real-time encode into H.264. See http://www.hauppauge.com/site/products/data_hdpvr.html for additional information.
Playback of HDTV using CPU
To playback HDTV content, plan on a powerful CPU if your video card does not provide support for offloading video decode. (See below for a description of VDPAU)
"How powerful?" depends on a number of factors, such as the capture resolution, whether the video is progressive or interlaced, and whether your display card has hardware-assist support for Linux.
The Simple Answer: Once you are in the 3.2 Ghz P4-class of CPU you should have no issues with viewing HDTV.
The Complicated Answer: For 720p content (1280x720), a 2.4GHz P4 should be sufficient.
For 1920x1080i->1920x1080p with the better deinterlacing methods done in real time a 2.4GHz CPU is taxed, but should work if you use "Bob and Weave" deinterlacing, or if you have an NVIDIA card with video decode acceleration.
Playback of HDTV using VDPAU
NVIDIA now incorporates MPEG-2 and H.264 decode acceleration in their binary driver; this is now officially supported in MythTV 0.22 or later. Use of VDPAU offloads the decompression and deinterlacing of video to the video GPU rather than the CPU of the frontend, so the CPU requirements are drastically lowered. A fanless frontend using an Intel Atom CPU running a single-core at 1.6Ghz is sufficient to decode and deinterlace MPEG-2 and H.264 if it has VDPAU supported video.
You may use the Firewire output of the Motorola DCT6200 or the SA3250. If your provider uses 5C encryption on a particular channel, you won't be able to get any content. Many users have resorted to using Firewire to change channels on their set-top-box and capture the High Def video using the Component output fed into a Hauppauge HD PVR.
USB Capture Devices
The Plextor ConvertX PVR devices are supported through Linux drivers available from http://go7007.imploder.org/ MythTV uses the Plextor to capture hardware encoded MPEG-4, so the host CPU requirements are low.
Hauppauge WinTV-PVR-USB2 and variants are supported by the Linux Kernel as of 2.6.18. Additional information is available at http://www.isely.net/pvrusb2/
IP Recorder (RTSP, RTS, UDP)
MPEG-2, MPEG-4 and H.264 stream recording is supported using the IPTV recorder in MythTV. This recorder expects the channels to be supplied as a m3u playlist. If your DSL/Fiber provider supplies television service, but does not provide a m3u playlist for the channels, you can construct one for your own use. You do not need to download it from the same server as the streams themselves, and it can also be read from a file if this is more convenient.
NOTE: Some DSL providers only allow you to use one recorder at a time, so you may need to limit yourself to one recorder in MythTV and turn off any set top box the cable provider sold or rented to you with your service. This limitation is independent of the bandwidth you have purchased.
The system needs a sound card or an on-board equivalent on the motherboard to play back and in some cases, to record sound. Any sound card that can be operated by the ALSA (Advanced Linux Sound Architecture) kernel modules will work with MythTV. However, some cards and drivers will provide better quality or compatibility than others.
NOTE: Analog video capture cards are the only ones which require a sound card for capturing audio. DVB, HDTV, and other hardware encoder cards all provide a combined audio / video stream. If you're not using a V4L analog device, you may skip this section.
The usual practice for capturing the audio associated with the video is to run a cable from an audio output on the video capture card to the Line input on a sound card. However, some video capture cards provide on-board audio capabilities that work with the kernel btaudio module instead, thereby eliminating the need for a cable. This is useful if you will be using multiple capture cards in a single chassis, since each capture card will not need its own sound card. Note that a separate sound card is still required for playback when using btaudio, and that often the audio recorded in this way will be mono only. See the btaudio section for more information.
NOTE: Plugging a Line-level device into the Mic input is not recommended. Line-level devices have higher voltages and can damage the sound card. In addition, even if it doesn't break your card, you will be getting Mono sound. See the Linux MP3 HOWTO at http://www.tldp.org/HOWTO/MP3-HOWTO.html for additional information.
Video Display Card
MythTV will work with just about any video card. However, it is highly recommended that you use a card which at a minimum supports XVideo (XV) extensions. If your card does not support XV, color conversion and scaling will be performed by your CPU rather than the video card. This is very CPU and memory intensive and will often result in dropped frames and a corresponding degradation of quality. Check the X documentation for details if you are uncertain about your preferred card. You may also run xvinfo; look for your video card to be listed as one of the adapters.
If you want to use MythTV with a standard television, you will need a physical connection from your video card to your TV set, which can either be a TV-out port on the card itself or an external adapter that converts the VGA signal to an appropriate video signal. "Appropriate" depends on a number of factors, such as video standard (NTSC vs. PAL), the type of input connection (Composite vs. SVideo), etc.
Note that with some video cards and X drivers, XVideo extensions are only supported on the VGA output, and not on the TV output.
Cards with TV-out
This section deals with a number of cards that are known to have TV-out ports. The list is unlikely to be complete, so if you know of others, please post a message to the mythtv-users mailing list so the information can be included in future versions of the HOWTO. The list is organized by manufacturer.
Reports here are based on what users of the cards have posted on the mythtv-users mailing list, so if you need configuration details, please search the archives at http://www.gossamer-threads.com/lists/mythtv/ using the card name in your search string.
Some NVIDIA cards with TV-out can be run using the standard nv driver in X, combined with the userspace application nvtv to control the TV-out port. See http://sourceforge.net/projects/nv-tv-out/ for details. Recent versions of the NVIDIA driver have better support for overscan and other features useful with TV-Out, so the nvtv application may not be required.
Some NVIDIA cards can be run with a proprietary NVIDIA X driver made available by NVIDIA. See http://www.nvidia.com/object/unix.html for more information.
NOTE: It's strongly recommended that you use the proprietary NVIDIA drivers; they have excellent support for VDPAU and ship with a good configuration utility. VDPAU provides hardware acceleration of video decoding, which is important if you want to watch High Definition TV.
External adapters convert standard VGA output to a form suitable for display on a television. The output format varies by region, since different countries have different TV standards. People on the mythtv-users list have mentioned these adapters:
- AITech Web Cable Plus, powered by external transformer or takes power from PS/2 keyboard connector, support resolutions up to 1024x768, outputs composite and SVideo, provides position adjustment.
- Averkey lite, powered by a USB port, has Composite, SVideo, YPbPr outputs; pan, brightness, overscan/underscan controls; supports up to 1024x768 outputs; and supports PAL and NTSC.
- ADS TV Elite XGA
- AverKey iMicro (comments are generally favorable)
- AITech Web Cable (comments are generally unfavorable, different than the "Plus" version above)
- TVIEW Gold (mentioned once, favorably)
There are a few ways of installing programs on Linux systems; you can either use a pre-compiled package, or install from a tarball after satisfying any prerequisites.
NOTE: you must have the MySQL database software installed on a system to store the master database. This does not necessarily mean that MySQL must run on one of the MythTV boxes. The minimum MySQL version is 5.0.15.
A number of people have created pre-compiled packages for MythTV that may make your installation easier.
BIG FAT WARNING: This HOWTO assumes that you have not installed MythTV from a package. All example command lines and file locations are based on the MythTV tarball defaults. Some packagers have modified the filenames, binaries and file locations to match what is commonly found in that distribution. Any issues with MythTV installed via a pre-compiled package MUST be raised with the packager.
If you use any of the pre-compiled packages you may not need to perform any additional configuration steps in this HOWTO. The next logical step is configuring MySQL, which you may or may not have to perform. See your package documentation.
Red Hat Linux / Fedora Core / MythDora
The definitive documentation on installing MythTV on Red Hat Linux / Fedora Core can be found in Jarod Wilson's mailto:email@example.com HOWTO at http://wilsonet.com/mythtv/ Just like 3rd-party packages, any 3rd-party documentation problems should be brought up with the 3rd-parties (maintainer, lists, bugzillas etc.).
Debian packages for MythTV and most of its add-on modules are maintained by Christian Marillat mailto:firstname.lastname@example.org and are available at http://www.deb-multimedia.org/ Installation instructions can be found on those pages as well. All of the prerequisites for MythTV are available as Debian packages, most of them from the official Debian archive.
After adding the appropriate commands to your /etc/apt/sources.list file you can run apt-get update and then execute apt-get build-dep mythtv which should install all the pre-requisites required to compile MythTV.
You may use the graphical tools that come with your distribution, or you can use command-line utilities. Either system will get the job done, and it all depends on your comfort level with Linux.
In order to compile MythTV, we need to make sure that the software it needs is installed. This list includes mysql, gcc, freetype2-devel, xorg-xserver-devel, qt-devel and lame. If you're going to use a remote control with MythTV, you're going to need the cdialog package in order to compile lircd if your distribution doesn't have a pre-packaged lirc. If you are using XMLTV as a grabber, you will need perl.
NOTE: Qt v4.5 or higher is required.
NOTE: If you are going to be using packages to install various components, you should be aware that not all packages include the necessary headers for compiling. If you're having trouble compiling, ensure that you've installed the -devel version of a prerequisite.
This section details the various methods for installing prerequisites from the command line.
Fedora / Mythdora
Assuming that you've configured ATrpms, you can execute:
# yum-builddep mythtv
Alternatively, you may use the build script located in packaging/rpm, or install the "requires" found in the mythtv.spec file located in the same directory.
You can run
$ sudo apt-get build-dep mythtv
Build-dependencies for MythTV can be satisfied by adding the following to your /etc/apt/sources.list
# Christian Marillat's packages (mplayer, lame)
deb http://www.deb-multimedia.org sid main
deb-src http://www.deb-multimedia.org sid main
# apt-get build-dep mythtv
# apt-get source mythtv --compile
System Configuration Requirements for Compiling MythTV
Before you compile MythTV from the current source tarball or from git, you may need to modify your system configuration in a few ways.
In general, if you install MythTV from pre-packaged binaries for your Linux distribution/version, you don't need to be too concerned about the issues in this section of the HOWTO - the install script for the packages should take care of them. However, this section is still recommended reading which may help if the packager skipped a step in their packaging.
Software requirements for compiling MythTV
MythTV is written in C++ and requires a fairly complete, but standard, compilation environment, including a recent g++ compiler, make, and appropriate header files for shared libraries. Any standard Linux distribution should be able to install a suitable compilation environment from its packaging system. Section 3.2 of this HOWTO provides some details of how to install the required environment for many distributions.
Subsequent sections of this chapter address the few oddities that you may have to adjust by hand before you compile MythTV.
The reference compilation system for MythTV is Ubuntu.
The runtime manager for shared libraries, /lib/ld.so, gets information about the locations and contents of shared libraries from /etc/ld.so.cache, a file created by ldconfig from information in /etc/ld.so.conf. Because MythTV installs shared libraries in /usr/local/lib, that directory needs to be added to the list of directories for ld.so to search when doing runtime linking of programs, if it is not already there. You do this, as root, by editing /etc/ld.so.conf, then running ldconfig. There are many ways to do this; to determine the way that your distribution is configured, type:
$ cat /etc/ld.so.conf
If you see that your .conf file consists of just the "include" line, then execute the following as root:
$ sudo bash
# echo /usr/local/lib >> /etc/ld.so.conf.d/mythtv.conf
If your .conf file has many individual entries in it, then type:
$ sudo bash
# echo /usr/local/lib >> /etc/ld.so.conf
Environment variable requirements for MythTV
QT libraries and binaries
The compiler needs to be able to locate QT binaries and libraries in order to compile MythTV. QTDIR needs to be set and the directory holding the QT binaries needs to be added to your PATH. Your distribution may already be making these changes as a part of the installation of the software prerequisites detailed earlier.
One way to do this is to open a shell and execute the following:
$ echo $PATH
$ echo $QTDIR
$ which qmake
If you don't see values like those above, do not proceed past this step until you have resolved this error. You may need to manually specify the QTDIR and PATH at the shell prompt before compiling.
Also, check that there has been a link created in /usr/lib/qt4/mkspecs called default. If not, you'll get errors during the compile. See the Troubleshooting Section for more information.
Downloading and compiling
Get MythTV from the http://www.mythtv.org web site. There are two installation methods you may choose from. The first is to download the latest release in tarball format and compile, but this is really only valid if you're reading this HOWTO on the very first day that a new release has been made, because the tarball is a static file and won't include any fixes for issues discovered after the tarball was created.
The recommended solution is to download the source using git to ensure that you've got the latest fixes.
When using git, there are some other choices that need to be made:
- Do you want to run the stable release of MythTV? If yes, use "git checkout fixes/0.26"
- Do you want to run the absolute latest developer code? If yes, you must join the http://www.mythtv.org/mailman/listinfo/mythtv-commits/ and http://www.mythtv.org/mailman/listinfo/mythtv-dev/ mailing lists to keep up to date with the current status of the code. Code obtained from git has no guarantees regarding stability, etc. The latest code will be in the "master" branch.
If you are in North America you will use the Schedules Direct grabber which is built-in to MythTV. You do not need to install XMLTV (so you may skip XMLTV-related instructions), but you need wget version 1.9.1 or higher.
Get XMLTV from http://sourceforge.net/projects/xmltv/files/ Download the latest version.
Configuring the Schedules Direct service
Schedules Direct is a non-profit organization which has licensed Television program data from Tribune Media Services and makes it available to users of Freeware and Open Source applications.
If you wish to use Schedules Direct, you'll need to establish a user account. Go to http://www.schedulesdirect.org and click on the "Membership" link.
Manually building MythTV
If you are going to use git, execute the following instructions to obtain the latest version of MythTV.
$ git clone https://github.com/MythTV/mythtv.git
To use the release version, you can execute the following after completing the previous command. You are strongly encouraged to use the release version.
$ cd mythtv
$ git checkout fixes/0.26
NOTE: Using a git version of the code allows you to stay up-to-date with changes. So, if there's an update to the 0.26 release and you originally obtained it using git, you could enter the mythtv directory and type "git pull", which will update your copy with the fixed version from the website. You would then recompile and install the updated code.
If you are using the tarball, then unpack it:
$ tar -xjf mythtv-0.26.tar.bz2
$ cd mythtv-0.26
If you wish to change options, run
to see what is available and to override any automatically detected options. See the config.log file after running configure to see previous runs.
$ make -j 2
The MythTV compile can take advantage of multiple CPUs, SMP and Hyperthreading. If you want to build MythTV on a multi-CPU machine (or with distcc), specify "-j numjobs", where "numjobs" is greater than 2. In the above example, we had two concurrent jobs executing, which is recommended for a single CPU system. Do not set the number of jobs too high, or your compile will actually take longer to complete than it would if you did a "normal" build.
Once the compile is done, switch to superuser:
$ sudo bash
# make install
Enabling real-time scheduling of the display thread
MythTV supports real-time scheduling of the video output thread. There are three ways to go about enabling this: You can use rlimits, you can use the realtime security module, or on older systems you can SUID the executable. Enabling real-time scheduling is optional, but can make the video display smoother, especially if you are decoding HDTV.
The rlimits method is the preferred method and is included in Linux 2.6.12 and above and requires PAM version 0.79 or above. Assuming anyone running mythfrontend is in the audio group and rlimits are supported, all you need to do is place this in your /etc/security/limits.conf
* - rtprio 0
* - nice 0
@audio - rtprio 50
@audio - nice 0
The second option is to use the Linux realtime kernel module. This will be phased out over time, but is currently supported by many distributions that do not yet support rlimits. If you are not using the distribution kernel you must configure your kernel with:
Security options : [*] Enable different security models
Security options : [M] Default Linux Capabilities
You may also need to install the realtime module, using your distribution's realtime package. Assuming the users who will be running myth-frontend will be in the audio group you can get the GUID of a named group like so:
$ grep audio /etc/group
If the number printed out from the grep was 18, you can now load this module as root before starting mythfrontend:
# modprobe realtime gid=18
run as root option (not safe)
The final and least preferred option is to set the sticky bit on the mythfrontend executable. This opens a security hole, but is the only option on systems that do not support either rlimits or the realtime module. This does not work on modern distributions either, and is not recommended on any system connected to the Internet. This may also make it impossible to debug MythTV without running gdb as root. If you would still like to do this, do the following as root:
# chmod a+s /usr/local/bin/mythfrontend /usr/local/bin/mythtv
Since MythTV uses a client/server architecture, multiple frontend computers can simultaneously access content on a Myth system. Live TV, watching and scheduling recordings, etc. are all possible from multiple frontends.
To get a better picture of what is needed to run a frontend, note the following:
- You do NOT need the MySQL server installed on your remote frontend
- You do NOT need XMLTV installed on your remote frontend
- You do NOT need to run the mythtv-setup program on your frontend machine
Other than the exclusion of the MySQL server and XMLTV, the MythTV compilation procedure is the same as when you're setting up both a backend and a frontend. However, you will need to install the database access libraries.
Once MythTV is compiled and installed:
Run the mythtv-setup program on your Master backend. Under the "General" menu, change the IP address of the current machine (by default, "127.0.0.1") to the real external IP address - 127.0.0.1 is the internal loopback address and no external machine can access it. Change the Master Server IP setting to the same IP address as well.
Run the mythfrontend program on your frontend machine, and a "Database Configuration" screen should appear. Set the "Host name" field to point to your Master backend's IP address.
You will also want to comment out any "log-bin" or "log_bin" lines in your my.cnf configuration file. This option will quickly fill your "/var" disk partition with many gigabytes of data, unless you are doing database replication and deleting these files regularly.
Red Hat Linux and Fedora Core
If this is the system maintaining the database, make sure that MySQL is running and started at boot. Click on Redhat menu>Server Settings>Services and enter the root password when asked. Check "mysqld" and then click Start. Click Save, then close the window.
This can be done from the command line by typing:
# /sbin/chkconfig mysqld on
# /sbin/service mysqld start
Setting up the initial database
This step is only required on the system maintaining the database, which may or may not be one of your MythTV boxes. If the database is on a non-MythTV machine you'll need to copy the database/mc.sql file to it.
To setup the initial MySQL databases: $ cd database
Mandriva and Red Hat Linux/Fedora Core
$ mysql -u root < mc.sql
$ mysql < mc.sql
# mysql < /usr/share/mythtv/database/mc.sql
NOTE: It is good practice to set a root password for MySQL. Instructions for doing so can be found on MySQL's web site at http://dev.mysql.com/doc/refman/5.5/en/default-privileges.html
Modifying access to the MySQL database for multiple systems
If you're going to have multiple systems accessing a master database, you must grant access to the database from remote systems. By default, the mc.sql script is only granting access to the local host.
To allow other hosts access to your master database, you can either configure MySQL database access with no security or with additional granularity.
The "%" is the wildcard character in MySQL.
This example has no security at all, and allows access from any host.
$ mysql -u root mythconverg
mysql> grant all on mythconverg.* to mythtv@"%" identified by "mythtv";
mysql> flush privileges;
For a more secure setup, you can restrict which machines or subnets have access. If you have a complete DNS system operational, you could do the following:
$ mysql -u root mythconverg
mysql> grant all on mythconverg.* to mythtv@"%.mydomain.com" identified by "mythtv";
mysql> flush privileges;
Finally, if you just want to restrict by IP subnet (in this example, the 192.168.1. network):
$ mysql -u root mythconverg
mysql> grant all on mythconverg.* to mythtv@"192.168.1.%" identified by "mythtv";
mysql> flush privileges;
You'll also need to check that the "networking" feature of MySQL is turned on. Check that /etc/mysql/my.cnf does not contain skip-networking. If it does, either remove that line or comment it out. Also verify that bind-address is set to your IP address instead of 127.0.0.1. If you change either of these items, restart MySQL.
NOTE: Your distribution may have a customized MySQL configuration file; in Mandriva, check /etc/sysconfig/mysqld for additional configuration.
TODO: UPDATE FOR NEW SOUND CODE
Setting up a remote control
MythTV does not have native remote control receiver and decoder software built-in. Instead, remote control functions are implemented by cooperating with lirc, the Linux Infrared Remote Control program. lirc handles the IR hardware and passes keystrokes to MythTV, which then acts as if the user had pressed the keys on the keyboard. The file keys.txt describes the keys used to control MythTV.
Compilation of lirc is outside the scope of this document.
You can dispense with lirc altogether by purchasing an IR keyboard and a learning remote control. The IR keyboard receiver plugs into your PC and you would train your learning remote to emulate the various keystrokes from keys.txt of your IR keyboard. Using this method removes lirc entirely from consideration - your remote will be sending keypresses that your PC "sees" on the keyboard port.
The "Big Picture" for lirc is that there are a few different things that fit together.
First, lirc has a portion which is connected to an IR receiver. The IR receiver senses the pulses and sends them to the lirc daemon. The lircd loads a file called lircd.conf which instructs it how interpret the IR pulses that it received and convert them to a human-readable name.
For example, the hardware may receive pulses may correlate to "Channel Up". The lircd.conf file will then contain a line that looks something like this:
The lircd.conf file can have multiple remote controls defined.
The second part is lircrc, which takes the name of the button which was pressed ("ChannelUp") in the above example, and associates that to an action to be performed by a program using the remote control. So in MythTV, ChannelUp means one thing, while in mplayer it means something different. lircrc gives you the flexibility of taking the name of the button and having it perform different actions depending on which program you're using at the time.
NOTE: The definitions in lircd.conf come from the user community, and there is no standard for the common button names. One lircd.conf file may contain a definition for a button called "ChannelUp", while another may contain a definition for "Chan+". Your lircrc file must therefore be configured appropriately, or it won't work.
Look for pre-made lircd.conf configuration files at http://lirc.sourceforge.net/remotes/ If you find one of your remotes either on the website or on your system, download or copy the file, name it lircd.conf and put it in your /etc directory. If you couldn't find your remote, you must make your own lircd.conf file.
To make your own lircd.conf file
$ irrecord myremote
Follow the on-screen directions to train your remote and define keys. If your remote ends up working well, you should consider submitting your lircd.conf file back to the lirc developers. Once finished:
# cp myremote /etc/lircd.conf
now try to start lircd again:
This takes care of the lircd portion, which "listens" for the IR signals. If everything went well, the install script for lircd put an appropriate configuration file for your remote into /etc/lircd.conf This file maps the buttons on the remote control to the IR pulses coming from the receiver.
The next step is to convert those signals into something that can be used to control MythTV. MythTV now includes native support for lirc and can interact directly with it.
$ cd mythtv/contrib/config_files/lirc
$ cp lircrc.example ~/.lircrc
$ cp lircrc.example.pinnaclestudiopctv ~/.lircrc
if you've got a Pinnacle Studio PCTV remote.
Start pressing the keys on your remote; irw will print the name of the button as it is defined in your /etc/lircd.conf. If you don't see anything at this point, you need to troubleshoot further by going back to the lirc home page and investigating from there.
If it is working, then press CTRL-C to abort the program. Once you know that your remote is working, you can either recompile MythTV with native lirc support by enabling it in configure or you need to run the irxevent program, which takes the key presses and sends them to MythTV. If you use native lirc support, you don't need to run irxevent. If you are going to use irxevent, then you need to run it like this:
$ irxevent &
If irxevent isn't running, then MythTV will not respond to your remote control unless you're using native lirc support.
Additional information for lirc
Take a look at the lircrc.example files in the contrib/configfiles/ directory. In my case, (Pinnacle Studio card) the channel up and down functions weren't working, due to the fact that the button names were different than the default lircrc.example file that came with MythTV.
The lircrc.example file has this:
begin prog = irxevent button = ChannelUp config = Key Up CurrentWindow end begin prog = irxevent button = ChannelDown config = Key Down CurrentWindow end
but the /etc/lircd.conf that comes in the lircd package defines the buttons for the Pinnacle Studio PCTV as:
rather than "ChannelUp" and "ChannelDown". I added the following to my /home/[yourusername]/.lircrc file:
begin prog = irxevent button = channel+ repeat = 3 config = Key Up CurrentWindow end begin prog = irxevent button = channel- repeat = 3 config = Key Down CurrentWindow end
which took care of basic functionality. Because the PCTV Studio remote has additional buttons, look at the contrib/config_files/lirc/lircrc.example.pinnaclestudiopctv for an example of how to define additional buttons, and how to debug potential button name conflicts between the lircrc.example file and how your remote defines the button names.
By examining the button names defined in /etc/lircd.conf and using the irw program to make sure that your remote is working, you can create the appropriate mappings in .lircrc to get excellent remote functionality with MythTV.
Note the repeat = parameter. This informs the irxevent program to pass through every third keypress. By default, lirc will only send one keypress to the application, even if you're holding down the key. The actual repeat = number will vary from system to system, so experiment and see which value works best for you.
By this point, all of the compile-time prerequisites have been installed, mysql is running and has had its initial database setup. It's now time to configure MythTV.
Configuring the Master backend system
Open a shell and decide where you will store your video files. This may be one directory or multiple directories on the same or different filesystems. There is no default directory used for new recordings, so you must create at least one storage directory and configure Myth to use it by running mythtv-setup. If you do not do this, then MythTV will be unable to record anything. The following example is specific for /var/video, but the same instructions would apply for any directory name you choose to use. See the Advanced Partition Formatting section for hints on creating a partition for MythTV.
# mkdir /var/video
# chmod a+rwx /var/video
TIP: Try not to have your video mount point on the same partition as your root partition, which could lead to the filling up of your root partition with video data if the mount fails. For example:
If /var/video is created on your root partition and you then perform a mount of another drive to this directory there won't be any problems if everything is working the way it should. However, if the mount fails for some reason, /var/video still exists, so MythTV will find the directory and write files to it. If your / mount point is space limited, /var/video will also be space limited, and it won't take long to fill the partition. This will cause a number of side-effects, most of them bad. Instead, create subdirectories as the destination for the storage group.
Your directory structure could then look something like this: /mnt/video/drive1/video /mnt/video/drive2/video
Your /etc/fstab would look like this: /dev/hdb1 /mnt/video/drive1 /dev/hdc1 /mnt/video/drive2
Because the Storage Group path is /mnt/video/drive1/video, if the mythbackend can only find /mnt/video/drive1 it will not write files to that share, because the "video" directory doesn't exist.
After you create the desired directory or directories for storing your video files, you will need to add them to the proper Storage Group using mythtv-setup. This procedure is described below in the Storage Groups section.
The first thing to configure is the Master backend system. If you are running multiple backend systems, the Master backend will make all decisions about which programs will be recorded on which tuners. If you have only one backend, then it will be its own master.
The Master backend will always choose the first available tuner in the same order as you add cards through "mythtv-setup". In other words, the second card you add will only be used hen there are two overlapping recordings, the third when there are three, and so on.
NOTE: It is possible to not have the cards on the Master backend be the first ones used. However, if you are new to MythTV it is easier to configure the Master backend first before moving on to the Slaves, at least until you become more familiar with the MythTV system. See Advanced Backend Configurations for information on configuring multiple backend systems in various ways.
Because MythTV uses a database to store all configuration variables, part of the bootstrap of MythTV is to indicate the location of the MySQL database server. If the frontend, backend and MySQL database server are all going to be running on the same box, you can continue to the next step. If not, you'll need to change the Host Name in the "Database Configuration" screen of the mythfrontend program. Run the setup program:
The backend setup program will start and offer you a number of choices. It is strongly recommended that you go through them in order.
The first question will ask if you wish to clear out your existing configurations for your capture cards. Initially, you should say "YES" so that there are no surprises later.
The next question will ask you if you wish to clear out your video source information. You should answer "YES" to this as well.
Once the graphical setup starts, you'll see that there the following choices:
- Capture Cards
- Video Sources
- Input connections
- Channel Editor
- Storage Directories
Use the arrow keys to move around, and press the space bar to select which option you wish to configure.
The first screen of the General configuration deals with IP addresses of the system that you're running mythtv-setup on and any master backend you may have. If you've only got one machine, then the default values are fine and you can move to the next page by pressing the space bar. If you need to move around the screen, use the arrow keys to move focus between settings, not the mouse.
If you will be deploying multiple backends, or if your backend is on one system and you're running the frontend on another machine then do not use the "127.0.0.1" IP address.
NOTE: If you modify the 127.0.0.1 address and use a "real" IP address, you must use real IP addresses in both fields, otherwise your frontend machines will generate "Unexpected response to MYTH_PROTO_VERSION" errors.
Changing any of the port settings is very strongly discouraged. (If you do accidentally change them, the defaults are 6543 for the master/backend server, and 6544 for the HTTP requests)
Once you're satisfied with the values, move the focus down to Next and hit the space bar.
The next screen details the Host-specific Backend setup. This is where you will set the specific directory paths for this particular backend. Make sure that you've followed the steps at the beginning of this section and created a directory that exists and that MythTV will have write privileges to. When you're done, press Next to continue, taking you to the Global Backend Setup.
On the Global Backend Setup configure your backend with the appropriate settings. Use the left and right arrow keys to iterate through the choices available on each setting, and the up and down keys to move between settings. Move to Finish when you're done and press the space bar, taking you back to the main configuration screen.
You should have no capture cards defined, so the highlight will be on (New Capture Card). Press space to begin.
Choose the appropriate settings for your particular tuner. Use the arrow keys to move around and to make your choices, and press RETURN when complete. Pressing RETURN will take you back to the Capture Cards screen; if you have additional capture cards in this machine, press the space bar when the highlight is on the (New Capture Card) row to define another card.
If you have made a mistake, you can delete a card by highlighting it and pressing the 'D' key, or you can highlight it and press the RETURN or 'E' key to edit it.
Once you have no additional cards to setup, press ESC.
NOTE: If you have a dual digital/analog card, such as the pcHDTV cards and some DViCO cards, then you should not configure this as two separate cards. Configure the digital portion as a DVB card, then click on the "Analog Options" button within the DVB configuration panel for the card and configure the analog portion of the card there.
When you start, the highlight should be on (New Video Source). Press the space bar to begin. The first field asks for the name of the video source. You may choose something easy to remember, like "Antenna" or "Cable". Once you've chosen a name, press the down arrow to move to the next field.
If you're in North America, change the grabber to "SchedulesDirect.org(Internal)", then continue pressing the down arrow to move to the next field. Fill in the username (lowercase only) and password that you have established with Schedules Direct, then move to the "Retrieve Listings" button and press the space bar.
NOTE: You need wget version 1.9.1 or higher to use Schedules Direct.
The mythtv-setup program will contact the Schedules Direct servers and get your account information. Once you're done, you may click the Finish button and skip the next few paragraphs in this document since they only apply to users that are using the external XMLTV script to get their guide data.
If you wish to continue using the XMLTV grabber, then move to the Zip/postal code field and put in the appropriate value. If you're outside of North America, then some manual interaction will be required with XMLTV. You may need to switch from the MythTV setup program to the console it was run on to interact with XMLTV.
Once you have chosen your provider, press RETURN to continue. XMLTV will now begin collecting the initial data for your location. The screen may blank for a few seconds to several minutes, depending on the load of the listings provider and the speed of your connection to the Internet. Be patient!
You will then be returned to the Video Sources screen. If you have multiple video sources available, such as Antenna, Cable, etc, go ahead and define them all, even if they're not all going to be physically connected to the master backend server. Once you're done, press ESC to return to the main screen.
The final configuration item is Input Connections. On this screen, you will associate the various video sources you defined earlier with a physical input to a encoder card. It's entirely possible that you have multiple tuners, and each tuner has a different input, so on this screen you let MythTV know which device will connect to which input source.
When you start this screen, you should see a listing of the various input connections available on each of the Capture cards you defined earlier. For example, you may have a capture card with a tuner, a SVideo and a Composite connection. If you wanted to associate the tuner (a.k.a., "Television") with an "Antenna" source you defined in Video Sources, you would move to the /dev/videodevice (Television) -> line and press the space bar. Using the left and right arrow keys will show you the various choices you have already created for video source. In our case, you would use the left/right cursor keys until "Antenna" was shown in the Video Source field. Press down to move to the next setting.
On the connection pane there is a "Scan for channels" button, if you are configuring a digital source such as a DVB card, you need scan for channels and you must do this before pressing the "Fetch channels from listings source" button. You may scan for analog channels on an analog input, but this is not needed.
The other button is called "Fetch channels from listings source". As long as you have a real listings source you should fetch channels from them for analog channels. You can do this for digital sources as well (unless the listing source is transmitted EIT data). If you are using XMLTV, you may need to switch from the MythTV setup program to the console it was run on to interact with XMLTV after pressing this button. It is possible to fetch the channels on the command line using mythfilldatabase. But if you need to do this, you will probably need to re-enter the MythTV setup program to configure the "Starting channel" setting for this source->input connection.
NOTE: If you have a Hauppauge PVR-500, you must think of it as two PVR-150's on a single PCI card. For example, if you have a single PVR-500 card, it will appear as /dev/video0 and /dev/video1. Each /dev/video device will have a Tuner input. Once you're done, press RETURN to go back to the Input Connections screen. You would then finish associating the video sources to any other hardware devices you have available.
NOTE: Don't add a video source to a hardware input if you don't actually have anything connected there. For example, adding "Cable" to the Tuner and to the Composite inputs without having something connected to Composite will lead to blank recordings.
Press ESC to return to the main menu, and press ESC again if you have no further items to configure, thereby returning you to the command line.
The channel editor is used to globally alter channel information, including items like hue, contrast, fine tuning and others. Users in North America shouldn't run the channel editor until you've completed the initial mythtv-setup and ran mythfilldatabase at least once to populate the database.
Storage Groups are lists of directories that are used to hold MythTV recording files, giving you a flexible way to add capacity to your MythTV system without having to use exotic solutions such as LVM, filesystem expansion or RAID Online Capacity Expansion. You can also use Storage Groups to organize recordings and to put recordings of a certain type into one subdirectory.
Storage Groups do not offer redundancy in case of hard drive failure, but unlike LVM, if you lose a hard drive, you only lose the recordings that were on that drive. With LVM, if you lose a hard drive, you will most likely lose everything.
How to use Storage Groups
By default, there is only one Storage Group called "Default", and it is used for all recordings and Live TV.
For example, if you have 5 hard drives in your system, your first hard drive could be your "boot" drive, and the remaining four could be dedicated to media storage. You could format the drives and mount them as /mnt/store/d2, /mnt/store/d3, /mnt/store/d4 and /mnt/store/d5.
Within each mount point, it's strongly recommended that you use a subdirectory and make that the destination path for the Storage Group. See the Tip in the "Configuring the Master backend" section for additional information.
You would then add the four subdirectories you created under the mount points (/mnt/store/d1/video, etc) into the "Default" Storage Group.
At recording time, if there were four simultaneous recordings, MythTV would put one recording onto each drive.
MythTV will balance concurrent recordings across the available directories in a Storage Group in order to spread out the file I/O load. MythTV will prefer filesystems that are local to the backend over filesystems that are remote until the local filesystem has 2 concurrent recordings active or other equivalent I/O, then the next recording will go to the remote filesystem. The balancing method is based purely on I/O, Myth does not try to balance out disk space unless a filesystem is too low on free disk space in which case it will not be used except as a last resort.
Or, say that you originally installed MythTV to a 750GB hard drive, and that hard drive is now filling up. You could simply add a new drive to your system, mount it and update the Storage Group to add the additional space.
You may create additional Storage Groups to store specific recordings in their own directories. Storage Groups are edited via the 'Storage Directories' section of mythtv-setup.
You can also create multiple Storage Groups to group recordings together; recording schedules now have an option to specify which Storage Group to use.
Storage Groups are global, but can be overridden on a slave backend by creating a local Storage Group by running mythtv-setup on the slave. If a problem occurs and the slave backend is unable to use the desired Storage Group, it will fail back and try the directories defined in the master's Storage Group.
There's also a special 'LiveTV' Storage Group, but the directory list starts out empty. If you add a directory to the Storage Group, it will be used instead of putting LiveTV recordings in the Default Storage Group and will allow you to put your LiveTV recordings on their own filesystem.
Of course, you don't have to do anything, and Live TV recordings will just go into the Default Storage Group where they'll be the first programs eligible for expiration if the system needs free space for recordings.
Usage information for all Storage Group directories is visible on the mythfrontend status screen as well as the mythbackend status webpage. MythTV is smart enough to determine which directories are on shared filesystems so it should not count free or used space multiple times if you have more than one directory on the same filesystem.
Migrating to Storage Groups
Migrating to Storage groups is very simple: if you have existing recordings in a storage directory, then the system will automatically add that directory to the Default Storage Group. If you then add additional directories to a storage group, the system is flexible enough to check all Storage Groups for a file before deciding that it can't be found, which means that you can use the mv command from the Unix command line to arrange files however you'd like.
Advanced: Algorithm used by the Storage Group
This section details the logic of the Storage Group allocation engine.
The current load-balancing preferences (in order) are:
- Local filesystems over remote
- Less-busy (less weight) over more-busy (more weight)
- More Free Space over Less Free Space
The "busyness" of a filesystem is determined by weights. The following weights are added to a filesystem if it is in use for the following things:
- recording = +10
- playback = +5 (mythfrontend)
- comm flagging = +5 (mythcommflag)
- transcoding = +5 (mythtranscode)
If a recording is due to end within 3 minutes, it is not counted against the weight of a filesystem. This is done to account for the pre/post-roll and start-early/end-late settings.
Run the mythfilldatabase program as directed. The master backend will obtain guide data for all the video sources you defined during setup.
NOTE: If you are using Schedules Direct and watching the output messages on the console or the log file it is normal to see a "401 Unauthorized" error followed by a "200 OK" when the connection to Schedules Direct is being established.
From : Sun Jun 13 05:00:00 2004 To : Mon Jun 14 05:00:00 2004 (UTC) --02:58:01-- http://datadirect.webservices.zap2it.com/tvlistings/xtvdService => -' Resolving datadirect.webservices.zap2it.com... 126.96.36.199 Connecting to datadirect.webservices.zap2it.com[188.8.131.52]:80... connected. HTTP request sent, awaiting response... 401 Unauthorized Connecting to datadirect.webservices.zap2it.com[184.108.40.206]:80... connected. HTTP request sent, awaiting response... 200 OK Length: unspecified [text/xml] [ <=> ] 114,125 63.57K/s 02:58:03 (63.53 KB/s) - -' saved  Your subscription expires on 08/20/2004 12:00:00 AM Grab complete. Actual data from Sun Jun 13 05:00:00 2004 to Mon Jun 14 00:00:00 2004 (UTC)
Once mythfilldatabase has finished, start the master server before continuing.
mythbackend will print information about connections and what it's doing to the console. If you'd like to see the options that are available for mythbackend, type mythbackend -h for help.
As of MythTV v0.26, the available options are:
mythbackend version: fixes/0.26 [v0.26] www.mythtv.org MythBackend is the primary server application for MythTV. It is used for recording and remote streaming access of media. Only one instance of this application is allowed to run on one host at a time, and one must be configured to operate as a master, performing additional scheduler and housekeeper tasks. Misc. Options: -d OR --daemon Fork application into background after startup. --noupnp Disable use of UPnP. -O OR --override-setting Override a single setting defined by a key=value pair. --override-settings-file Define a file of key=value pairs to be loaded for setting overrides. -p OR --pidfile Write PID of application to filename. --printexpire Print upcoming list of recordings to be expired. --printsched Print upcoming list of scheduled recordings. --setloglevel Change logging level of the existing master backend. --setverbose Change debug mask of the existing master backend. -h OR --help OR --usage Display this help printout, or give detailed information of selected option. --version Display version information. --testsched do some scheduler testing. --user Drop permissions to username after starting. Logging Options: --loglevel Set the logging level. All log messages at lower levels will be discarded. In descending order: emerg, alert, crit, err, warning, notice, info, debug defaults to info --logpath Writes logging messages to a file in the directory logpath with filenames in the format: applicationName.date.pid.log. This is typically used in combination with --daemon, and if used in combination with --pidfile, this can be used with log rotators, using the HUP call to inform MythTV to reload the file --nodblog Disable database logging. -q OR --quiet Don't log to the console (-q). Don't log anywhere (-q -q) --syslog Set the syslog logging facility. Set to "none" to disable, defaults to none. -v OR --verbose Specify log filtering. Use '-v help' for level info.
Running mythbackend as a daemon and using the logfile option will allow you to have mythbackend automatically start up during boot. You can follow the steps outlined in the section called Automatically starting mythbackend at system boot time for configuration steps.
If you enable the --logpath parameter, you will want to keep your logfiles rotated (so that they don't fill up a partition). See the section called Automatically rotating logs for more information.
Configuring a non-master backend
Ensure that you've granted access to the master MySQL database for remote backends as discussed in the section titled Modifying access to the MySQL database for multiple systems and that you have the correct IP address for the database server in the "Database Configuration" screen of the mythtv-setup application on this slave backend.
NOTE: Slave backends must not run a local MySQL daemon. By default, they will connect to their local daemon rather than the central database, causing unexpected behavior such as empty "Watch Recordings" lists and a failure to locate the Video Sources defined on the master backend. Modify the /usr/local/share/mythtv/mysql.txt file on all slave backends to ensure that the DBHostName has the address of the MySQL server. Caveat: You may make a slave backend the primary MySQL server, or run a non-MythTV database on a slave backend as long as you have edited the mysql.txt file on all systems and made it consistent. There can be only one authoritative MySQL database in a MythTV system - errors such as the one 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 slave backend can't communicate with the master backend due to IP address misconfiguration then MythTV will not function properly.
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.
Configuring and running mythfilldatabase
NOTE: mythfilldatabase might take a while to complete, depending on any number of factors, most of which you can't control. It's best to just let the program run to completion. mythfilldatabase --help will give a full listing of the options available.
mythfilldatabase --manual is another option; the manual option will allow you to fine tune channel frequencies and specify which channels will be added to the database.
mythfilldatabase --file is an option if there isn't an XMLTV grabber for your country, but you do have an XML formatted listings file created by some other program.
mythfilldatabase --xawchannels is an option if you have used xawtv to fine-tune your channels and would like to import the fine tuning offsets into MythTV.
mythfilldatabase --refresh-today will only pull guide data for today (in case of late-breaking changes to the schedule).
Periodically running mythfilldatabase
In order to keep your database filled, mythfilldatabase should be run once a day.
To use MythTV's built-in capability to run mythfilldatabase, you'll need to run the mythtv-setup application. From the main menu, select "General" and advance to "Program Schedule Downloading Options" (the eleventh screen). Select the checkbox, "Automatically update program listings", then complete the options as you see fit. The mythbackend program will now run mythfilldatabase for you.
Grabbing channel icons for Schedules Direct users
While the Schedules Direct TV listings service has several advantages, it does not support grabbing logo icons for the stations you receive. However, there are utilities provided with MythTV which you may use to grab your initial set of icons and to keep them updated if your lineups change.
First, you need to generate or obtain an XML file with the information for your stations.
If you have XMLTV software installed, there is a perl script in MythTV's contrib/icons/master_iconmap directory which will generate this file for you. Run the command:
$ mkdir ~/.mythtv/channels
$ ./channel_icons.pl --find-missing --rescan
If you do not have XMLTV software installed and do not want to install it for the sake of this minor task, there is a generic contrib/master_iconmap.xml which you can copy and use but this may not be as complete as using the specific information for your service.
Once you have an iconmap.xml file, add the icon information to your database and grab any new icons with the command:
$ mythfilldatabase --import-icon-map iconmap.xml --update-icon-map
Once you have completed the configuration of your backend systems, the next step is to configure the frontend client.
When you start mythfrontend for the first time, it will attempt to connect to a configuration database on the local machine. If there is none, a "Database Configuration" screen will appear, and you will need to fill in some details. The "Host name" field needs the backend or database server's IP address or DNS name, and the User or password fields may need to be set to match your database user accounts. After editing those fields, press Enter twice to write these configurations on your local machine, and attempt to connect to the database. If you make any mistakes, the screens will pop up again.
Now that mythfrontend has started up, you should have a number of buttons/choices. Before doing anything, go to TV, then to Setup and configure the frontend client.
The General screen has configuration items that don't really fit anywhere else. The first few configuration items ask you to indicate the number of seconds to record before or after a program, which is useful if the broadcast network or your system clock are out of sync and will help prevent you missing the beginning or end of a program. To change the value, use the left and right arrow keys to increment and decrement the number of seconds. When you're satisfied with the result, use the down arrow to put the input focus on the Next button or press RETURN to continue to the next page.
The next page has a number of options to do with how channels are displayed on your system. The help text will give you more information. Move the focus to Next and press the space bar to continue.
The last General page sets up some final configuration items. See the help text for more information.
This set of screens is mostly concerned with how MythTV will look on your system. From here, you can choose different themes and set the resolution of your system.
Here you can adjust settings for the Electronic Programme Guide (EPG).
Depending on your capture card, MythTV offers different video encoders. The following types of hardware encoding cards are supported:
- MJPEG - Zoran-based cards; see http://mjpeg.sourceforge.net
- MPEG-2 - iTVC15/16 based cards (Hauppauge PVR-250/PVR-350); see http://ivtvdriver.org
- HDTV - pcHDTV cards; see http://pchdtv.com and the Air2PC-ATSC-PCI
- H.264 - HD PVR
- DVB - cards supporting DVB, ATSC or ISDB; see http://linuxtv.org
- HD Homerun
For cards without hardware encoding capabilities (all cards supported by V4L not listed above), Myth includes two methods for software encoding: RTjpeg and MPEG-4. RTjpeg has significantly fewer CPU demands than MPEG-4, but it generates larger files than MPEG-4 for a given recording.
Any cards which simply demodulate MPEG-2 which has been encoded by the broadcaster (HDTV/ATSC/DVB cards) will not offer much in the way of configuration because the broadcaster will be choosing the bitrate, etc.
For all other cards, configuration is done through MythFrontend. Selecting 'Recording Profiles' from the 'TV Settings' screen will list the profiles currently available for the cards in your system.
Depending on what types of cards you have installed you may see:
(Create new profile group)
Hardware MPEG Encoders
Hardware MJPEG Encoders
The '(Create new profile group)' option will allow you to create custom profiles in case you have multiple backends. Note that custom profiles are per backend and card type. If you have two MPEG-2 encoders in a given backend system, creating a custom profile will affect both of them. This option should not be needed otherwise.
The 'Transcoders' group is a little different from the others. Selecting this group will result in a menu with the following options: 'RTjpeg/MPEG-4' and 'MPEG-2'. These types indicate what transcoder options will be used for a given input type (i.e. the 'MPEG-2' settings would be used to transcode MPEG-2 files into MPEG-4. The source of the MPEG-2 stream (DVB, HDTV, or PVR-x50) does not matter. Configuration of the options is the same as below (although any resolution settings will be ignored).
Selecting any of the other options will show a new screen with a list of four profiles:
- Live TV
- Low Quality
- High Quality
The Default profile will be used for any recording which does not otherwise have a specific profile assigned. The 'Live TV' profile will be used when watching TV. The remaining two profiles are available for customizing to allow for more precise control over what quality is used for a given program.
Selecting a profile will allow you to adjust the relevant options for that card. The most significant setting is the recording resolution, but you can also choose encoding format, audio format, and tweak other encoder specific properties.
NOTE: although the width and height can be changed to almost anything, if you start MythTV and don't see video or you get "segmentation fault" errors, it is likely that the video4linux (v4l) subsystem did not like the height and width parameters specified. It's best to leave the default as-is until you're sure that MythTV is operational.
See the What capture resolution should I use? How does video work? section for more information.
The keys.txt file describes what the various keyboard commands are. If you have loaded mythweb, you may change the default keys to your liking.
|Arrow keys||used to move the highlight point around|
|ALT-F4||exit out of the application|
|Space/Enter||take action on the item under the highlight point|
|P||play in both "Watch a Recording" and "Delete a Recording"|
|D||delete in both "Watch a Recording" and "Delete a Recording"|
|O||to list the upcoming episodes for the currently selected show on the EPG, "Program Finder", "Program Recording Priorities", "Fix Scheduling Conflicts" or search results screens|
|I||to get additional information about the currently selected item. Pressing 'I' while on the Recording Options screen will take you to the Advanced Recording Options screen.|
Watching TV or a recording
|Up or down||keys change the channel|
|num pad||Type a number to enter a channel number or jump amount (HHMM format)|
|P||pause / play. You may also add an explicit keybinding for 'Play' through MythWeb, returning you to normal speed if you are in slow motion, rewind fast forward or pause mode.|
|C||change inputs on TV Tuner card|
|I||puts the On-screen Display up again. During playback, 'I' toggles between position and show description info. If a jump amount is entered, jump to that position.|
|M||menu (allows access to the EPG and many other useful features)|
|Page Up||jump back the configured number of minutes (default is 10)|
|Page Down||jump ahead the configured number of minutes (default is 10)|
|End or Z||skip to next commercial break marker|
|Home or Q||skip back to previous commercial break marker|
|T||toggle close caption support Pressing 0-9 (preferably 3 times) + T changes teletext page and turns on teletext.|
|F||rotate between the various Picture Adjustments (Colour, Hue, etc.) While Picture Adjustment is on-screen, use Left and Right arrows to adjust. These settings adjust the look of the video playback, and are independent of the G-key settings used at record-time.|
|[ or F10||decrease volume|
|] or F11||increase volume|
|| or F9||toggle mute|
|/||jump to the next "favorite" channel|
|?||mark/unmark the current channel as a "favorite"|
|U||increase the play speed|
|J||decrease the play speed|
|A||adjust time stretch (speed up or slow down normal play of audio and video)|
|W||cycle through zoom modes: Half, Full, Stretch|
|Ctrl-W||force aspect ratio of video to be treated as either 4:3 or 16:9|
|S||toggle display of the Program Guide (EPG).|
|F8||toggle the sleep timer 30m->1hr->1hr30m->2hr->Off|
|#||display the Program Finder.|
|CTRL-B||Jump to the beginning of the recording / ringbuffer|
|+||Switch between audio streams|
|Left||skip back the configured number of seconds (default is 5). If a jump amount is entered, jump back that amount (HHMM format).|
|Right||skip forward the configured number of seconds (default is 30). If a jump amount is entered, jump ahead that amount (HHMM format).|
|<||starts sticky rewind mode. If a jump amount is entered, jump to that position (HHMM format).|
|>||starts sticky fast forward mode. If a jump amount is entered, jump that amount from the end (HHMM format).|
|In sticky fast forward or rewind mode:|
|Left/Right||increases the ff/rew speed|
|0||plays at normal speed, but leaves the time indicator on screen|
|1 or 2||plays back more slowly than normal ff/rew speed (1 is slowest)|
|3||plays back at normal ff/rew speed|
|4-9||plays back faster than normal ff/rew speed (9 is fastest)|
|Space||exits fast forward or rewind mode|
|While video is paused:|
|Left||rewind 1 frame|
|<||rewind 1 second|
|Right||advance 1 frame|
|>||advance 1 second|
Watching TV only
|G||rotate between the various Picture Adjustments (Colour, Hue, etc.) for recording. These values affect the look of the resulting .nuv file, and are independent of the playback picture settings. While Picture Adjustment is on-screen, use Left and Right arrows to adjust.|
|H||Channel history. Each repeat steps back through the previous channels.|
|O||Turns on 'Browse' mode, allowing user to browse channels and program info while watching current show FullScreen.|
|Y||switch between multiple capture cards. NOTE: you will lose your LiveTV buffer on your current card. Useful for different-sourced cards (such as Dish Network on one, HDTV over-the-air on another card.)|
LiveTV Browse Mode
|Left||browse program prior to current listed program|
|Right||browse program following current listed program|
|Up||browse program on channel above current listed channel/program|
|Down||browse program on channel below current listed channel/program|
|/||browse program on next favorite channel|
|0-9||enter a channel number to browse|
|Space/Enter||change channel to channel of current listed program|
|R/r||Toggle recording of current program (cycles through types)|
|ESC/O||Exit Browse mode|
Playback Recording Zoom Mode
|Left||Move video to Left|
|Right||Move video to Right|
|Up||Move video Up|
|Down||Move video Down|
|Space/Enter||Exit Zoom mode leaving picture at current size and position|
|ESC||Exit Zoom mode and return to original size|
If you have two or more tuner cards
|V||toggle Picture-in-picture on or off|
|B||toggles the window focus (lets you change channels on the PiP window)|
|N||swaps the two channels by changing channels on both cards|
Watching a recording only
|Space/Enter||set a bookmark at that point. Next time you start the recording, you will automatically jump forward to this point and clear the bookmark.|
|X||queues the current recording for transcoding|
|O||brings up menu to allow toggling settings such as Commercial Auto-Skip, Auto-Expire, etc.|
|D||exits the current recording and displays the Delete menu|
|E or M||enters/exits edit mode.|
|In edit mode|
|Left/Right||move forward and backward|
|Up/Down||alter the amount of time you jump forward and backward. Increments are: nearest cutpoint, nearest video keyframe, 1 frame, 0.5 seconds, 1 second, 20 seconds, 1 minute, 5 minutes, and 10 minutes.|
|PageUp/PageDown||move forward and backward to the nearest cut point|
|< or >||move forward or backward by 10 times the normal jump amount|
|Space/Enter||allows you to set or delete a cut point|
|Z||loads the commercial skip list (if one exists) into the cutlist|
|C or Q||clear all cut points in the cutlist|
|I||Inverts the cutlist|
|Arrows||are used to move the highlighted program point around|
|A, D, S, W||perform the same as left, right, down and up|
|PageUp/PageDown||move the channel list up or down a page|
|Home/End||move the highlight left or right by one day|
|Ctrl+Left or <||move the highlight left by one page|
|Ctrl+Right or >||move the highlight right by one page|
|9, 3, 7, 1||(like a numeric keypad) perform the same as PageUp, PageDown, Home and End|
|E||allow you to schedule a recording. If you select "Record this showing" while watching Live TV you can "Instant Record" a program.|
|Space/Enter||when watching LiveTV will change to that channel and exit the EPG if the selected show is in progress or starts within 15 minutes; or otherwise will allow you to resolve conflicts or change overrides. If the program is not already scheduled to record, it will instead act like pressing E|
|X||change the channel to the currently selected channel without leaving the EPG (Most useful in the alternate EPG)|
|ESC or C||exits without changing the channel|
|R||change the current item from Recording/Not-Recording. Successive keypresses cycle through the scheduled recording type list.|
|?||mark/unmark the current channel as a "favorite"|
|/ or 4||toggle the guide listing between all channels and filtered "favorites"|
Setting Program or Channel Recording Priorities
|Right||increases priority value|
|Left||decreases priority value|
|1||sorts by title|
|2||sorts by priority|
|Home/End||toggle sort priority|
|E||edit recording options|
|ESC||commits changes and exits|
Viewing Scheduled Recordings/Resolving Conflicts
|1||show all recordings|
|2||show only important recordings|
|Home/End||toggle show showing all/important|
|E||edit recording options|
|Space/Enter||resolve conflict or override|
Viewing Search Listings
|Home||change to the previous view if applicable|
|End||change to the next view if applicable|
|M||select another view if applicable. In the title and description search popup, press M again to edit or delete the selected view.|
Recording Profiles Setup Screen
|D||on a custom profile group displays a popup to delete the group|
In the Watch Recordings screen, Recording Groups allow you to separate programs into user-defined categories, such as "Kids", "Alice", "Bob", etc. This can be used to reduce clutter, or to segregate content if you use the PIN function.
|M||to change the view or to set a group password or change recording and storage options. Press M again to toggle between menus.|
Watch Recordings Screen
|1 or F1||Meaning of the icons|
|/||Tags a recording. Tagged recordings can be played either in order or shuffled and deleted as a group. You can also change the recording group for several recordings at once by tagging them and using the Menu (m) button, selecting "Playlist options", then "Change Recording Group".|
|?||Clear the tagged list.|
|<||Previous recording group|
|>||Next recording group|
If you are using MythTV with just a remote control then it is suggested that you map the remote control keys as described below. Your remote control may not have the same set of keys as those named below, the names are only a suggestion that roughly correspond to the function.
If you are adding new key bindings to the program then consideration of this suggested list will help users with remote controls.
This list assumes a minimal remote control that only has 20 keys, nearly all features can be used with this configuration. If you have more keys then you can access all of the features. With only 16 keys most features are usable.
|Remote Control||LIRC Keystroke||Function|
|0 - 9||0 - 9||channel selection, EPG navigation, ff/rew speed setting (with stickykeys)|
|Left Arrow||Left||scroll left, rewind|
|Right Arrow||Right||scroll right, fast forward|
|Up Arrow||Up||scroll up, channel change up|
|Down Arrow||Down||scroll down, channel change down|
|Select / OK / Play||Space||Select item, play (with stickykeys) set bookmark|
|Cancel||Escape||Cancel, quit playback|
|Menu||m||EPG (from watching TV) edit (from playback).|
|Other key 1||i||Information|
|Other key 2||c||Change tuner card input|
Using themes with MythTV
TODO - this is all over the web now.
Adding support for an external tuner
MythTV supports changing the channel on an external tuner. If you have an external tuner, such as a DirecTV or digital cable set top box, you should add /usr/local/bin/changechannel to your Input Connections in the mythbackend configuration GUI.
However, there is not changechannel program per-se, because this is going to be dependent on what sort of external tuner you have. Look in the contrib/channel_changers directory for a number of programs and scripts which may be used to change channels. Once you find one which works, copy it to /usr/local/bin/changechannel
Feel free to browse some of what sort of hardware is available at http://store.snapstream.com/accessories.html or if you wish to assemble your own, rather than purchase, the following may be helpful http://www.dtvcontrol.com/ for cable pinouts.
What does the MythTV Shutdown/Wakeup function do? The scheduler on the Master backend (MBE) keeps track of the idle status of the entire MythTV system, including the Slave backends (SBE). If it considers the system to be idle, and thus ready to shutdown, it sets the wakeuptime to the time of the next recording and then proceeds to shut down all Slave backends and then itself. Once it is time to begin recording, the Master backend and the Slave Backends are automatically woken up. This system allows MythTV to record like a normal VCR, thereby conserving power when not in active use.
In order to use the Shutdown/Wakeup function there must be some method of waking up the Master backend. There are any number of solutions, but we will discuss in detail two possibilities:
- Use another server that runs 24/7 and have it send a WakeOnLAN (WOL) packet to wake the Master backend. This assumes that you have the WOL tools installed, and that your Master backend motherboard supports WOL.
- Use your motherboard's BIOS wakeup capability. You'll need a motherboard that supports BIOS wakeup, and some tools. See http://www.mythtv.org/wiki/ACPI_Wakeup for details on the best ways to accomplish this.
A deeper look into the operation
The scheduler keeps track of the idle status of the MythTV system. To determine whether or not the MythTV system is idle, the following conditions must be met for a period of time defined in the "Idle timeout (secs)" parameter.
- no client is connected to the server
- no recording (neither LiveTV nor a regular recording) is currently taking place
- no recording starts within a definable amount of time ("Max. wait for recording (min)")
- the "pre Shutdown check-command" returns 0
If we get to this idle state the Master backend will set the wakeuptime using the "Set wakeuptime command", which is the same for WOL and BIOS wakeup. The Master backend will then shut down the Slave backends and itself using the "Server halt command".
One caveat is that the scheduler tries to guess if the Master backend was started by a wakeup call or by the user. If it thinks it was woken up by a user, it blocks shutdown until a client connects to the Master backend, after which it will behave as described above. To disable this feature, unset "Block shutdown before client connected" in the mythfrontend Setup->Setup->General screen.
Once it is time to startup the system, the Master backend is woken up first and will wakeup the Slave backends using the "Wake command for slaves". At this time, there is no support for starting only the required Slave backend, so all Slave backends will startup.
Setting up the MythTV side of this extension
There are a number of options that are used to control the Shutdown / Wakeup feature.
- "Idle timeout (secs)" is the time the server waits while idle until a shutdown occurs.
- "Max. wait for recording (min)" is the time the Master backend waits for a recording without shutting down. For example, this would be used to prevent a 10 minute system shutdown if a recording is set to start 15 minutes from now.
- "Startup before rec. (secs)" Sets how long before a programmed recording the MythTV system will be woken up. This should be roughly be the time your systems need to bootup, and if you have Slave backends, you'll need to ensure this value is long enough for all your machines to perform their bootup cycle.
- "Wakeup time format" is the format of the wakeup time that is given in the "Set wakeuptime command" as a parameter "$time". You need to set this according to your wakeup mechanism. If you need seconds since the epoch (1970-01-01) set the "Wakeup time format" to "time_t".
- "Set wakeuptime command" is the command executed to set the new wakeuptime.
- "Server Halt Command" is the command executed to shutdown the Master backend and the Slave backends.
- "pre Shutdown check-command" is used to give a "Go/NO-GO" decision from a non-MythTV source. This command is executed immediately before the shutdown would occur. The return value is use to make the following choices:
- If it returns a "0" the shutdown will occur as scheduled.
- If it returns a "1" the "idle timeout" will be reset and the system waits again for the timeout.
- If it returns a "2" the entire shutdown sequence is reset. This means that a new client connect is needed before a shutdown occurs, unless you have the "Wait for client connect" setting disabled, in which case this is the same as returning "1". An example of a use for this return value is to prevent the shutdown if a user is currently logged in, or if a specific program (i.e. transcode, automatic updates, etc.) is currently running. If you don't need it, leave the field blank.
The "WakeOnLan settings": These settings have nothing to do with using BIOS or WOL wakeup, they are the same for both.
- "Master backend" This setting defines timings for the frontends to wakeup the Master backend using WOL. Useful if your frontend can emit a WOL packet so you don't need to physically go to the Master backend if you're trying to watch TV.
- "Reconnect wait time (secs)" is the time the frontend waits after executing the "Wake command" before attempting to retry the connection. This should be roughly the amount of time your Master backend needs for bootup. Set to "0" to disable. The frontends will retry to connect for "Count of reconnect tries" times before giving up.
- "Wake command for slaves" is the one command executed to wake your Slave backends. This should be a script that contains the calls to wakeup all Slave backend systems.
Using WOL to wake your Master backend
To use WOL to wake your Master backend you will need a WOL capable Master backend, a machine that runs 24/7 which can execute an at-job and nc (netcat) on the Master backend. I use some little bash scripts to make my DSL router wakeup my mythbox if required.
Replace $SERVER and $PORT with your own settings! On my Master backend I have a script that gets called as 'setwakeuptime command' which looks like the following:
echo $@ | nc $SERVER $PORT
This simply cats the parameters (that is $time) to my 24/7 server. On my $SERVER I have (x)inetd listening on $PORT starting a little script which cares about setting the at-job. The following additions are necessary on the $SERVER:
If you use inetd, add the following to /etc/inetd.conf:
mythwake stream tcp nowait mythtv /usr/sbin/tcpd /usr/local/bin/mythwake
If you use xinetd, save the following as mythwake in your /etc/xinet.d/ directory:
- socket_type = stream
- wait = no
- user = mythtv
- protocol = tcp
- id = mythwake
- server = /usr/local/bin/mythwake
and add the following to /etc/services:
Finally, /usr/local/bin/mythwake looks like:
#this should be a command to wake your server
#first we need to delete all wake jobs in queue
for JOB in atq | cut -f 1 ; do
- atrm $JOB;
#now we read the date from 'nc'
#now set the atjob
echo -e "$WAKECMD" | at $date ;
SECURITY WARNING: Be sure to secure $SERVER:$PORT from untrusted networks, because this allows 3rd parties to run arbitrary code on your server!
Using BIOS wakeup to wake your Master backend
See http://www.mythtv.org/wiki/ACPI_Wakeup for the best ways to accomplish this.
Wakeup the MySQL server using WOL
If your MySQL server and your Master backend are not on the same machine, you can have the Master backend wake your MySQL server using WOL. You will find the settings for this in the second page of the mythtv-setup program, or at the end of mysql.txt. The meanings are the same as discussed in "The WakeOnLan settings" above.
If, for example, one of the Slave backends is also your desktop computer, you could simply use a little script as 'server halt command' which first calls /sbin/shutdown -t TIMEOUT where TIMEOUT is a value sufficient for you to react. You could then popup a window using cdialog, asking for permission to shutdown. If you cancel the shutdown, simply call /sbin/shutdown -c
If you get "nvram-wakeup: /dev/rtc: Device or resource busy" your set-wakeuptime-script should stop the program that uses /dev/rtc before setting the wakeuptime.
Controlling the mythfrontend via telnet
To use this feature you must first enable it in Settings>General>General
The network control listens on port 6546, as demonstrated below:
$ telnet basement 6546
Connected to basement.
Escape character is '^]'.
MythFrontend Network Control
Type 'help' for usage information
jump - Jump to a specified location in Myth
key - Send a keypress to the program
play - Playback related commands
query - Queries
exit - Exit Network Control
Type 'help COMMANDNAME' for help on any specific command.
# help jump
Usage: jump JUMPPOINT
Where JUMPPOINT is one of the following:
channelpriorities - Channel Recording Priorities
channelrecpriority - Channel Recording Priorities
deletebox - TV Recording Deletion
deleterecordings - TV Recording Deletion
guidegrid - Program Guide
livetv - Live TV
livetvinguide - Live TV In Guide
mainmenu - Main Menu
Please note that this feature only allows one connection at a time, so any new connections will automatically terminate prior ones.
The MythTV master backend is responsible for managing the schedule for all TV tuner cards on the master and any slave. Its job is to search the TV listing for the shows you have requested and assign recordings to the TV tuner cards. If none of the shows that you've chosen overlap, it simply records all of them. However, if there are shows where the beginning and end times overlap, the scheduler follows rules that you've specified or makes logical decisions about what would be best if you haven't expressed your preference. Further, the "Upcoming Recordings" page allows you make specific decisions about what you really do and don't want to record.
When you choose a show that you would like to record from the Options Page, there are eight different types of rules to help the scheduler find which showings you would like to record.
- Single Record -- record only this title at this specific time and this station. This is the best way to be sure that a certain showing will be recorded. However, if the TV listings change and the show is not broadcast at that time, the show will not be recorded but will be marked as Not Listed to let you know that you should investigate.
- Find One -- this will record a title once from any of the times that appear in the TV listings. This is useful for recording a movie or special that has multiple showings because it allows the scheduler to choose one that doesn't conflict. It is not a good choice for recording a single episode of a series because it records the first available showing of the title without regard to the episode information.
- Record Weekly -- this records a show whenever the title is listed on the same channel, weekday and time. Note that if the TV station changes the schedule for a special episode, it would not be recorded. However, you can add a Single record for the special episode. If there are no matching showings in the TV listings, a Not Listed item will be added to your schedule for the next time slot to let you know that you should investigate.
- Find Weekly -- this will record a title once per week from any of the times that appear in the TV listings beginning from the time of the showing that was selected when the rule was set. This is useful for news, current events or other programs where the same episode is shown several times each week but the listings may not include descriptive information. This may not be a good choice if there are different episodes shown during the week.
- Record Daily -- this records a show whenever the title is listed for the time and station on any day of the week. Here again, a show will not be recorded if the time was altered by the station. If there are no matching showings in the TV listings, a Not Listed item will be added to your schedule for the next time slot to let you know that you should investigate.
- Find Daily -- this will record a title once per day from any of the times that appear in the TV listings beginning from the time of the showing that was selected when the rule was set. This is useful for news, current events or other programs where the same episode is shown several times each day but the listings may not include descriptive information. This may not be a good choice if there are different episodes shown during the day.
- Channel Record -- records one showing of each unique episode from any of the times the title is listed on this station. This is perhaps the most common rule to use for most shows.
- Record All -- records one showing of each unique episode from any of the times this title is listed on any channel. This can be useful if a station has sister stations where shows are rebroadcast allowing the scheduler to record rebroadcasts on the other station when the original airing cannot be recorded.
By default, all shows you select have equal value to the scheduler. There are a set of rules to make good choices when two or more shows are in conflict. However, priority values let the scheduler know what you prefer so that it can set the schedule based on your preferences.
Initially, recording rule priority values are set to zero. You may choose to leave everything at "0" and let the scheduler follow rules to guess what you might prefer when there are conflicts. However, if you have one or two favorite shows, you may want to increase the priority value so the scheduler will know that you would prefer recording these over other shows. You might use certain values to rate shows so that all favorites are 2. good shows are 1 and extra 'filler' shows are all -1 for example. You could sort each title on the "Set Priorities" page to have a unique value so the scheduler can know which show you'd prefer versus any other show. The choice and style are entirely up to you. However, the more information you give to the scheduler, the more likely it will make the choices you would prefer in the first place.
The scheduler choices are based on the total priority for a showing by adding up all priority factors that match the showing. By default, most of these factors are "0" but you may use any combination to express your likes and needs.
- Per record rule
- this is the "priority" selection in the "Scheduling Options" section of the options page and this value is included for any showings that match the recording rule. You may choose to only use these values and not use the other factors for the sake of simplicity and clarity.
- Per record type
- Setup->TV Settings->Recording Priorities->General allows you to add to the priority based on the type. It may make sense to increase the value for "Single" so that by default they have an extra advantage over other shows. The default is +1. You may want to decrease the value for Find rules so that they will be less likely to interfere with regularly scheduled shows and will be more likely to record in a non-conflicting time instead. The default is -1.
- Per channel
- Setup->TV Settings->Recording Priorities->Channel Priorities can be useful if you believe that you prefer any of the shows on certain channels. This would give all shows on a channel an advantage by default.
- Input priority
- in the "mythtv-setup" program, the "Input Connections" section allows you to add additional priority in the "Input priority". This is simply another priority factor but has an interesting effect. If a card input has a higher value than the other cards, the scheduler will see that you would rather record showings of episodes on this input rather than a showing on other inputs. If you have multiple cards of different quality, you may want to set input priority to encourage the scheduler to record shows on your best card(s) whenever possible. This can also be useful if you have multiple video sources which include the same stations. For example, with digital and analog cable you could increase the digital cable input preference by 1 to tell the scheduler that you want to record from the digital channel whenever possible but the channel on the analog input could still be used when the digital input is busy.
- Custom Priority
- this allows you to add any specialized factors you would like in order to influence scheduling decisions. See the Custom Priority section below.
For any single showing of any show you've chosen to record, these factors are added together to find the "total priority". This is the priority that the scheduler uses to decide which showings are given the first choice when filling in the schedule.
The scheduling priority of a show may also be used to determine auto-expiration of recordings when disk space gets full (see Auto-Expire, below).
Singles will record without regard to duplicate matching.
The standard recurring methods of All, Channel, Weekly and Daily use the descriptive information in the TV listings to try to record only one showing of each unique episode. However, this goal is sometimes complicated by the fact that the stations may not include a description for a specific episode but use a generic description for the series instead. When there is a generic description, the default behavior is to assume that it may be an episode that you have not seen and to record it for you. One of the duplicate matching options is "Record new episodes only". If this is selected, listing that have an original air date of more than 14 days earlier are considered repeats and are not eligible to record. Generally, generic episodes will be marked as repeats also.
Because of generic episodes and other situations, MythTV offers an alternative approach where shows may be recorded by choosing from multiple showings even when the descriptive information is not reliable. All of the "Find" record types look for matching titles in the listings. If there is a showing with specific episode information and that episode has recorded before, that showing is marked as previously or currently recorded. The scheduler will then choose to record the earliest non-conflicting showing from any of other remaining showings regardless of the descriptive information.
Generally, Find One is most useful for movies or specials and the Find Daily and Find Weekly rules are best for news or current events shows that are repeated. However, these may be useful in other situations where the standard recording rules may not work correctly.
As you add more shows that you would like to record, the scheduler will eventually encounter conflicts. If there are two shows at the same time and you have two or more TV tuner cards, both shows will record. However, if there are more shows than cards, the scheduler will have to decide what it thinks it should not record based on the information you have given. If you see an unexpected situation you are not "stuck" with the scheduler's choice. You can still tell the scheduler exactly which shows you do want to record and/or don't want to record in any situation.
Here are the actual decisions made by the scheduler as it fills in the schedule.
- Currently recording beats not currently recording
- A recording in progress can not be moved to another input or time so it "wins" its current timeslot.
- Single, Daily, or Weekly rules with no match are marked Not Listed
- If these or Overrides do not match the current listings because the listings have changed, they are added to the schedule and marked to indicate that they will not record.
- Rules that could record beat rules that can not record a showing
- If two rules match the same showing of a program, a rule marked as inactive or a showing marked as a repeat, for example, yield to the other rule.
- More specific record type is used in place of less specific
- If two rules match the same showing of a program, preference is given to Don't Record then Override, Single, Find One, Record Weekly, Find Weekly, Record Daily, Find Daily, Channel and finally All.
- Higher total priority beats lower total priority
- This is the core of the scheduling process. Episodes of the highest priority show are placed on the first available input followed by the next highest priority show and so on.
- Future start time beats past start time
- If there is an episode in progress and also a later showing of the same episode, it is better to record the complete episode. If there isn't another showing, it will start recording immediately to record the remaining portion. This should only happen if you add a new rule while the show is in progress or if the master backend is started after the start time of a scheduled show.
- More specific record type beats less specific record type
- If two shows are on at the same time and have the same total priority but different types they will be sorted by Single then Find One, Record Weekly, Find Weekly, Record Daily, Find Daily, Channel and finally All. This only applies if the priorities are the same.
- If both start times have passed, later start time beats earlier start time
- This attempts to miss the least amount of time.
- If neither start time has passed, earlier start time beats later start time
- This helps assure that the earliest showing of an episode has the advantage.
- Lower input id beats higher input id
- The scheduler fills in open time slots on the first available input for the video source. The next input is used when there is another show already placed for the card of the first input.
- Older record rule beats newer record rule
- If two shows are still equal after all of these other checks, the show whose record rule was added first is preferred over a more recent addition.
- Postpone showings to resolve conflicts
- If Reschedule Higher Priorities is set or if a conflict has the same priority as a show that was scheduled at the same time, the scheduler will check to see if a scheduled show can be moved to another input or later matching showing without creating a new conflict so that the conflicting show can be scheduled to record.
Reschedule Higher Priorities
Setup->TV Settings->Recording Priorities->General has a checkbox for "Reschedule Higher Priorities" which tells the scheduler to try to be a little smarter in certain situations. If this is checked, the scheduler will look for situations where a show cannot record because all inputs for the channel are used for higher priority shows. It will check to see if any of the other shows could be recorded at another time so that the conflicting show can be recorded in its place.
Generally, this is a good strategy but there are tradeoffs. If a higher priority show is postponed, you will not get to watch it until it is recorded in the later timeslot. There is also a risk that the TV listings may change and the later showing may go away. In this rare case the higher priority show may never record. On the other hand, if you do not use this option you will miss recording some lower priority shows unnecessarily unless you manually make similar changes.
By using Reschedule Higher Priorities, the scheduler will do a better job of recording as many of your shows as possible when left unattended. It will also be easy to see that shows have been marked to record at a later time. You can then decide for yourself when you would prefer to record the first showing by clicking "Record anyway".
Controlling Your Schedule
The Manage Recordings->Upcoming Recordings page is your control center for the MythTV scheduler. Unlike other DVR systems, this one page gives you all of the information and tools you need to see all of your alternatives and make whatever adjustments you desire.
The upper half of the screen has a scrollable box listing items that match your record rules sorted by time. The lower half shows the details for the highlighted item. There are two 'views' available. Press "1" to include all of the items that match record rules even if they do not need to be recorded. Press "2" to focus on just the things that will record and items that may need your attention. The message in the upper right-hand corner will remind you when there are conflicts that would prevent one or more shows from being recorded.
The items in the list are colored in the record color for things that will record, white for things that may need attention, gray for those that do not need to record and yellow when there is a time conflict. Items at the top of the list may also be highlighted indicating that the recording is in progress.
Along with the channels, start times and titles, the right-hand column has a status code. Numbers indicate which card number has been assigned to record the show. Letters are used to indicate the reason that something will not be recorded. Just below the box is a short status message for the highlighted item that indicates the type of record rule that was matched, the "total priority" for this showing and a one or two word explanation of the status code. If you press SELECT, you will see more information about the status.
There are a few status codes that may require your attention. "C" indicates that there are more overlapping shows to record than there are TV tuners to record them. "L" indicates that the scheduler found that it may be better to record a later showing of this episode. These states happen as a result of your choices and should normally reflect your preferences. However, you may notice situations where you would like to modify the scheduler's initial choices.
The first thing you can do is to highlight an item and press INFO to see the recording options page. From this page you can change the record rule type, the duplicate matching rules, or raise or lower the priority to resolve whatever problem you noticed.
Additionally, you can treat any individual showing as an exception that you do want to record or don't want to record. To use these "override" features, highlight the item and press SELECT. You will see a message explaining the current status and at least an "OK" button to exit without making changes.
For items scheduled to record, there will be a button for "Don't record" which will prevent recording this showing but will still allow the same episode to record in the future. If there is episode description information, you may also see a button for "Never record". This prevents recording this showing and tells MythTV to remember that this is an episode that you've seen or don't need to see if it is ever in the TV listings again.
For items that are not scheduled to record, the message will describe the reason and in the case of "C" or "L" it will include a list of the shows that are scheduled to record instead. For any item that could potentially be recorded there will be buttons for "Edit Options" and "Add Override". "Edit Options" will allow you to change the options for the existing record rule such as raising the priority so that the show will record. These changes would apply to this and all future showings that match this record rule. "Add Override" will allow you to set options that apply to the specific showing without affecting the recurring record rule.
If you return to an override page after an override has already been set, you will also see a "Clear Override" to undo your changes. This option makes it very easy to try out some "what if" attempts when deciding on your best strategy in a difficult situation.
For a recording in progress, there will be a "Change Ending Time" button. This will take you to the options page for a Single or Override or create an Override if it is a recurring rule. Here you can go to the Recording Options section to change the program end time offset. If you extend the end time so that it overlaps upcoming recordings, the schedule will change to accommodate the new end time. This may cause a conflict or later showing even for a show with higher priority. Therefore, it is a good idea to check your schedule after changing the end time of a recording in progress.
Each recording rule can be configured with a different recording profile. For example, colorful cinematography can be configured with a "High Quality" profile, while "talking heads" interviews shows can be configured with a "Low Quality" profile. These recording profiles need to be configured before using them (see Recording, above).
For organization of the "Watch Recordings" screen and the MythWeb interface, recordings can be assigned into "recording groups".
This allows you to select any special "Storage Groups" you may have created to determine where recordings from this rule should be stored on your disks. The "Default" storage group is always available.
This selects a set of pre-configured playback parameters which can be created and edited in Setup->TV Settings->Playback Groups. When the recording is played, the values from this playback group will be used. This allows you to choose a default time stretch value, skip and jump amounts appropriate for this type of television program.
MythTV will "autoexpire" old recordings to make room for new recordings when disk space gets filled up. This option can be set to "Don't allow auto expire" to prevent these recordings from being automatically deleted when disk space fills up.
The default setting is for all scheduled recordings to be eligible for auto-expiration; this can be changed in the Settings->TV Settings->General page by manipulating the "Auto Expire Default" checkbox.
The default auto-expire policy is "Oldest Show First"; the oldest recordings are deleted first. The "Lowest Priority First" method chooses to expire the lowest-priority recordings first.
An episode limit can also be configured to limit the maximum number of episodes recorded of a single series, to restrict that series' disk usage. If this is set, you can further decide what to do when this limit is reached; either stop recording that series, or to delete the oldest episodes in favor of the new ones.
Post Recording Processing
Select whether or not to automatically detect commercials for these recordings. Commercial Detection parameters can be set in Setup->TV Settings->General.
Select whether or not to automatically transcode recordings to save disk space. Before using this, you must first enable auto-transcode in the recording profile and configure the transcoding parameters; see Recording, above.
User Jobs allow you to configure up to 4 custom commands to run on recordings. They can be configured in mythtv-setup. The following tokens have special meaning when used in the User Job commands:
|%CATEGORY%||Program subject category, may be undefined.||Both|
|%DESCRIPTION%||Program title, may be undefined.||Both|
|%DIR%||Event: myth://IP:6543/file.mpg, Job: actual directory, may be undefined prior to recording start.||Both|
|%ENDTIME%||Recording end time (estimated) yyyyMMddhhmmss.||Both|
|%FILE%||Recording file, may be undefined prior to recording start.||Both|
|%FINDID%||Find ID, for DB lookups.||Event|
|%INETREF%||String, e.g. ttvdb.py_123456|
|%JOBID%||The id of this job in the mythconverg jobqueue table.|
|%ORIGINALAIRDATE%||Original Air Date of recording.||Both|
|%PARENTID%||Parent recording rule ID, for DB lookups.||Event|
|%PROGEND%||Program's scheduled end time.||Both|
|%REACTIVATE%||1 if this recording was reactivated after failing to start on time, 0 otherwise.||Event|
|%RECID%||Recording rule ID, for DB lookups.||Event|
|%RECORDEDID%||Recorded rule ID, for DB lookups.||Both||v29.2|
|%RECSTATUS%||Recording status as an integer for completeness, not currently useful.||Event|
|%RECTYPE%||This is the recording rule type as an integer, in the priming script example this could be used to do an extensive priming prior to some recordings and not others. These integers are listed in recordingtypes.h in the RecordingType enum.||Event|
|%SECS%||Time until upcoming recording starts.||Event|
|%SENDER%||Origin of event (hostname.)||Event|
|%SUBTITLE%||Program subtitle, may be undefined.||Both|
|%TITLE%||Program title, may be undefined.||Both|
|%VBIDEVICE%||E.g.: --verbose --logpath --loglevel --quiet --nodblog [--syslog (if non Windows)].||Event||30|
|%VERBOSELEVEL%||Bit mapped decimal value. See: https://code.mythtv.org/cgit/mythtv/tree/mythtv/libs/libmythbase/verbosedefs.h||Both|
|%VERBOSEMODE%||E.g.: --verbose --logpath --loglevel --quiet --nodblog [--syslog (if non Windows)].||Job||0.25|
|%VIDEODEVICE%||String identifying the physical video device||Event||30|
|l/L||Lock||This could be seen by PVR-250/BTTV users.|
|a/A||PAT||Any recording transmitted in MPEG. Maps MPEG program numbers to PIDs where we find PMTs.|
|m/M||PMT||Any recording transmitted in MPEG. Maps program to audio, video and other stream PIDs.|
|g/G||MGT||ATSC only. Tells us on which PIDs to find VCT and other ATSC tables.|
|v/V||VCT||ATSC only. Maps ATSC channels to MPEG program numbers, and provides additional data.|
|c/C||Crypt||Is the stream encrypted?|
|n/N||NIT|| DVB only. The network information table is intended to provide information about the physical
network. It is used by the channel scanner to find other transports.
|s/S||SDT||DVB only. Maps DVB Channels to MPEG program numbers, and provides additional data. Stays at 's' if no SDT with matching original_network_id and transport_id are seen.|
+ Except for t/F/T, lower case = seen, upper case = seen and good
What is the difference between the various Hauppauge PVR models?
This is covered in the hardware section, and extensively covered on the Hauppauge website. (http://www.hauppauge.com/site/compare/compare_pvr.html) Please check the Hauppauge website for the most accurate information.
- PVR-150 comes in a number of versions:
- The PVR-150 (Model 1045) is the retail kit. It comes with a remote control and an IR Blaster. It does not have a radio tuner.
- The PVR-150 MCE (Model 1042) will usually come in a plain white box and is sold as an OEM device. It does not come with a remote control, since it's usually used as the second, third, etc capture device.
- The PVR-150 MCE Kit (Model 1062) does not have a radio tuner and comes with a Microsoft Media Center remote control instead of Hauppauge's.
- The PVR-150 low profile (Model 1086) is a low-profile card. It has a radio tuner and is approximately half the height of a standard card. However, it comes with a low-profile PCI bracket, so it is not suitable for use in a standard PCI slot without removing the bracket, which may not be worth the trouble.
- A PVR-250 (Model 980) is a retail kit which comes with an IR receiver and a remote control.
- The PVR-250 MCE (Model 975) contains a FM radio tuner. The PVR-250 MCE does not contain a IR receiver or a remote.
- The PVR-250 Rev 1 contained an MPEG-2 decoder. However, this function was not connected to any output jacks, and there doesn't appear to be any way to pull decoded video from the card, so it's a fairly useless feature.
- The PVR-350 (model 990) has the features of the PVR-250 as well as being able to decode MPEG-2. The encode and decode functions may be used simultaneously. However, the decoder function is only available once Linux has started, so you will not see any boot-time messages. Also, the card is not capable of resolutions higher than 720x480, so it cannot be used with HDTV. Make a conscious decision (and ask for advice on the mailing list) that you want to tradeoff potential HDTV use in the future compared to video quality. Finally, support for the MPEG-2 video decoding offload has been removed from within MythTV.
The X-driver for the PVR-350 support playback using Xv efficiently but does not support any other 2D or 3D acceleration. For some application this may place a large load on the host CPU, some will run without any problem and others (mplayer, xine, xmame etc.) should be configured to utilize the Xv interface.
- PVR-500 is a dual-encoder version of the PVR-150 card, so you can simultaneously record two different programs at the same time, because there are two encoder chips on the PCI card. Hauppuage has also installed an onboard splitter, so you can use one COAX to feed both tuners. Current versions of the PVR-500 should come with an adapter to allow you to connect a second S-Video or composite input, but this will take up a second PCI slot. Early adopters may need to purchase this item separately.
Changing channels on an external Set Top Box
If you need to use an external Set Top Box (STB), such as for satellite TV or for digital cable you will need some way for MythTV to tell the STB to switch to a new channel. There are several methods:
- Use an IR blaster. An IR blaster is an infrared transmitter connected to your computer. When MythTV needs to change channels it will send IR pulses, thereby emulating a remote control.
- Use a direct serial connection. Some STB's have a serial port on the back, although it may not look like a serial port. It may look like a phone jack, or a strange VGA connector. It may be labeled "Low Speed Data". A direct serial connection is more reliable than an IR blaster. Not all STB's that have a Low Speed Data port have it enabled; you may need to convince your service provider to turn it on. Stating that you have a Tivo may help; the Tivo has a direct-connect capability.
- Use a firewire connection. There is a 6200ch.c in the MythTV contrib directory which may work for you.
Configuring one machine to flag all commercials
Commercial flagging can be CPU intensive. By default, the backend that created a recording is the one which will flag commercials. You may wish to use a different machine to run commercial flagging.
On the slower machine:
- Start the mythtv-setup program. Advance through the pages until you get to the Job Queue page. Turn off the setting that says "Allow Commercial Detection jobs", thereby preventing any commercial flagging jobs from running on this machine.
- Next, make sure that "Run Jobs only on original recording host" is turned OFF so that new jobs are allowed to run anywhere.
- Restart mythbackend since it only reads this setting when it starts up.
On the faster machine:
- Start the mythtv-setup program. Advance through the pages until you get to the Job Queue page. Ensure that "Allow Commercial Detection jobs" is turned ON for this machine.
- Run mythjobqueue. mythjobqueue will examine the JobQueue and run any jobs it finds. mythjobqueue should be left running so that it will pick up any new commercial flagging jobs that are added to the queue, otherwise new jobs will be added to the queue and your programs won't be flagged until you run manually run mythjobqueue.
Using this technique it's possible to add commercial flagging machines as needed, even on systems that aren't running a backend. It's also possible to run the commercial flagger in a virtual machine environment such as VMWare.
Advanced Partition Formatting
The partitions that your distribution sets up for you may not be optimized for large files.
Unlike a typical filesystem, a MythTV video partition is usually a very large filesystem filled with a fairly small number of large files. Filesystem I/O is usually not an issue, even in multi-tuner and/or multi-frontend setups.
There is however, one aspect of filesystem performance that can have a bearing on the performance of MythTV. In Linux, deleting a file will utilize I/O bandwidth until the deletion has been completed. If deleting the file takes long enough, the video capture buffer may overrun, thereby resulting in dropped frames. Some filesystems are faster at deleting files than others and, for multi-gigabyte MythTV video files, these differences can be significant.
Although done in 2006, there are published tests (http://www.debian-administration.org/articles/388 and http://linuxgazette.net/122/TWDT.html#piszcz) that provide insight into filesystem performance under conditions relevant to MythTV usage. In addition, some limited testing (archived at http://www.gossamer-threads.com/lists/mythtv/users/52672) with very large files (10 gigabytes) was reported in the MythTV Users mailing list.
Ext2 was the defacto standard Linux filesystem for many years. It is stable, provides good I/O performance and can quickly delete large files. The primary disadvantage of Ext2 is that it is not a journaling filesystem, so a file system consistency check (fsck, which is normally only performed after a system crash) can take many hours on a filesystem the size of a typical MythTV partition.
Ext3 is Ext2 with a journal, so your biggest gain is that in case of a crash and reboot you won't have to wait very long for your partition to be remounted.
There are options available when formatting an Ext3 partition, as in:
# mkfs.ext3 -T largefile4 /dev/hdb1
This example assumes that /dev/hdb1 has already been created using fdisk. If you're using LVM, /dev/hdb1 may be something like /dev/VGforMyth/video.
The "-T largefile4" option creates one inode per 4 megabytes, which can provide a few percent more storage space. However, tests indicate that using the "-T largefile4" option can drastically increase the amount of time required to delete a large file and thus it should only be used with encoder settings that produce small video files (YMMV).
You can check on your filesystem using the dumpe2fs program. See the man page for details.
Ext4 is Ext3 with extents and many other features, making it more suitable for large file systems. It has addressed many of the performance issues with ext2 and ext3 and can be used for MythTV video file storage.
JFS (Journaling File System) is a journaling filesystem originally developed by IBM for AIX which was later released as open source. While not as common as Ext3 or ReiserFS, it is distributed with RedHat 9 (RH9), Fedora Core and Mandriva as well as other distros. According to tests, JFS is the file deletion speed king, deleting virtually any file in under one second, even files as large as 10 gigabytes.
XFS is a journaling file system originally developed by SGI for Irix, and later released as open source. While not a part of the default RedHat Linux 9 or Fedora Core installation (although it is a part of Mandriva and Fedora Core 2+), it can be easily installed via ATrpms. XFS provides deletion speeds for large files only slightly slower than JFS. XFS file systems provide higher I/O rates than JFS, albeit at a higher CPU loading. This may cause issues if you do not have the spare CPU capacity to handle XFS, potentially leading to dropped frames.
Caching support for Schedules Direct
MythTV 0.20.2 or later supports caching of downloaded information from Schedules Direct, so devices that share a common source do not require multiple downloads.
Before beginning, perform a backup of your existing database. See "Saving or restoring the database" for instructions.
In the following scenario, assume that you have the following:
- A PVR-150 MPEG-2 encoder card connected directly to a CATV source.
- A PVR-250 MPEG-2 encoder card connected via S-Video to a CATV Set Top Box.
What we are going to do is to create a single lineup at Schedules Direct and then create two Video Sources which use the same login information but have different channels associated with them.
On your Schedules Direct account, create a lineup that has all of the channels that you can receive. Because we have a Set Top Box (STB), choose a Digital lineup. Yes, this means that you may have 900 channels in this lineup, but that's OK.
Use the Schedules Direct channel editor and unselect any channels that you can't tune without the STB. This will usually be channels higher than 125, but check your CATV provider lineup if you're not sure. Once you've deselected them (using a click on the first channel you can't receive and then a shift-click on the last channel you can't receive will deselect all the channels in between those two.) click the Save Changes button at the bottom of the screen.
In mythtv-setup, create a Video Source with an appropriate name. "SD-Analog Only" will be used in this example. Click "Retrieve Lineups" and select the digital lineup you just created at Schedules Direct.
Click "Finish" to return to the Video sources selector and then press the ESC key to go back to the main screen.
Now choose Input Connections. Select the PVR-150 which is connected directly to the CATV. Set the Video Source to "SD-Analog Only" and click "Fetch channels from listings source".
Set the start channel to an appropriate value.
NOTE: There is a bug where the "Fetch" command may not work; you can tell that the Fetch did not retrieve any channels in one of two ways: in the text-mode console, you will see a connection to Schedules Direct, but it doesn't appear to retrieve any channel information:
2007-08-25 15:03:05.526 New DB DataDirect connection
2007-08-25 15:03:05.526 Connected to database 'mythconverg' at host: localhost
2007-08-25 15:03:05.536 DataDirect: Your subscription expires on 11/23/2007 01:12:10 PM
2007-08-25 15:03:05.707 New DB connection, total: 3
2007-08-25 15:03:05.707 Connected to database 'mythconverg' at host: localhost
2007-08-25 15:03:05.708 sourceid 2 has lineup type: CableDigital
2007-08-25 15:03:06.623 Data fetching complete.
2007-08-25 15:03:06.624 DataDirect: Deleting temporary files
or, the "Please add channels to this source" message in the "Starting channel" field stays on the screen.
If either of these happens, save the information on this screen by clicking the "Finish" button. Exit back to the Input connections screen by pressing ESC, then select this Input Connection again. This time the Fetch will work and the "Please add channels to this source" message will disappear.
If you look at the text-mode console, you'll see this if the channel retrieval is working:
2007-08-25 15:04:32.437 New DB DataDirect connection
2007-08-25 15:04:32.437 Connected to database 'mythconverg' at host: localhost
2007-08-25 15:04:32.447 DataDirect: Your subscription expires on 11/23/2007 01:12:10 PM
2007-08-25 15:04:32.622 New DB connection, total: 3
2007-08-25 15:04:32.622 Connected to database 'mythconverg' at host: localhost
2007-08-25 15:04:32.623 sourceid 2 has lineup type: CableDigital
2007-08-25 15:04:33.418 DataDirect: Adding channel 41 'AMC' (AMC).
2007-08-25 15:04:33.422 DataDirect: Adding channel 32 'A & E Network' (AETV).
2007-08-25 15:04:33.425 DataDirect: Adding channel 66 'Black Entertainment Television' (BET).
2007-08-25 15:04:33.427 DataDirect: Adding channel 180 'Bravo' (BRAVO).
2007-08-25 15:04:33.430 DataDirect: Adding channel 51 'ABC Family' (FAM).
2007-08-25 15:04:33.432 DataDirect: Adding channel 146 'Country Music Television' (CMTV).
2007-08-25 15:04:33.435 DataDirect: Adding channel 39 'CNBC' (CNBC).
2007-08-25 15:04:33.437 DataDirect: Adding channel 36 'Cable News Network' (CNN).
2007-08-25 15:04:33.440 DataDirect: Adding channel 35 'CNN Headline News' (CNNH).
Repeat the Input Connection configuration for any other capture devices that are connected directly to the CATV system. You do not need to click Fetch once you've done one successful download of the channel information - the Starting channel should be automatically populated.
Go back to Schedules Direct and re-enable the channels that you had previously deselected, then click Save Changes.
Create a new Video Source, here called "SD-All Digital Channels". Perform the same "Retrieve Listings" you did before.
Go back to the Input Connections screen, select the PVR-250 which is connected to the STB, assign the "SD-All Digital Channels" video source and perform a retrieve channels. This will pull down the complete channel listing, but only for this device.
When mythfilldatabase runs, it will cache the "big" download which is appropriate for the STB, and then copy the information to the channels that can only be accessed without the STB. But by default mythfilldatabase is going to notice that the "Analog only" video source is missing the channels that are in the Digital lineup you created at Schedules Direct, so we need to override the addition of new channels.
When you run mythfilldatabase to populate your database, you'll need to run it like this:
$ mythfilldatabase --remove-new-channels
You will also need to modify how the mythbackend calls mythfilldatabase when it performs its automatic listings update. In mythfrontend, select "Setup" -> "General".
Continue press ENTER until you reach the Mythfilldatabase configuration screen. In the "mythfilldatabase Arguments" field, type
then press the TAB key until you reach Finish, then press ENTER to save. You can then press ESC until you return to the main screen.