This is meant to be a simplified overview of the various pieces that together compose MythTV. It is hoped that after studying this, users new to MythTV will better understand how it works and be able to make more intelligent planning decisions about their own installations. It would actually be a good idea to read this document carefully, and then read the installation documentation in it's entirety before you actually begin any work at all.
MythTV is basically a big multimedia jukebox primarily meant to record television programming to be watched later ("time-shifted") when it's more convenient to the viewer. There are plugins to handle video files that have been manually added to the system (MythVideo) and plugins to play music that has been manually added to the system (MythMusic). Conceptually there are three parts of the system that perform different functions, and which talk to each other at various points, as illustrated by the diagram appearing on the right.
...also known as "the free parts".
There are three main pieces to the software end of MythTV, but only two of them are actually the MythTV distribution. These can all run on a single machine (provided you have the 1.2Ghz or so of CPU power) or on separate machines, depending on what you'd like to do and just how robust you'd like your home theater media system to be. It's important to understand what role each of these pieces plays in order to be able to make correct decisions about what pieces to run on your hardware.
MythTV keeps track of programming schedules, configuration information, upcoming recording events (i.e., what you wanted it to record) and the inventory of (both recorded and imported) media MythTV has in a relational database. The database is probably the most important component of MythTV because without it, absolutely none of MythTV can function.
MySQL is the only supported relational database that works with MythTV. MySQL 5.0 is probably the best version to choose (where you should ensure you have version 5.0.15 or higher). Don't get crazy and try using beta or development versions of MySQL (like 5.4.x or 6.x) unless you're a very experienced programmer and fully intend to take on debugging and patching things to work without any outside help. (This is directed at you, Gentoo users.)
The database server is going to need a meager amount of disk space to store the actual database information about what has been recorded and when. The amount of disk space it needs varies depending on a number of factors (whether or not you have a massive music collection, or whether you only have four or five broadcast channels to worry about) but ranges between 256Mb of disk space (comfortable minimum) and 1Gb of disk space (not many people will ever get beyond this). Also, if there's any part of your setup that you'll want to arrange regular backups for, it's the database files. Without them, MythTV will no longer have any idea of what things it has recorded, and there's no easy way to put things back into the database once those records have been lost. (Good thing it will usually all fit on a single rewriteable CD!)
Unlike the other components of MythTV, there may be only one database server involved. If you want to (for whatever reason, probably masochism) spread the database out to multiple machines using some kind of clustering or replication scheme, go right ahead, it's your equipment--just understand that MythTV only needs one database server and doesn't really have a use for any others.
The backend server is the drab little workhorse part of MythTV that takes care of managing tuner cards, recording actual programs, deleting expired programs, and downloading updated TV schedules. When using hardware encoders and digital tuners, none of these tasks require significant processor, and the backend only needs enough throughput to send content to the backends. The backend also runs one Jobqueue, so it may still be advantageous to have a powerful system to perform whatever batch tasks you may have.
The backend needs to be able to communicate with the database to find out when it's supposed to record programming, as well as keeping track of what's already been recorded so that it won't record the same thing twice (unless you wanted it to do that).
The backend is typically where you're going to want to have the bulk of your drive space allocated for storage. Standard definition recordings will typically use 1-3GB per hour, and high definition recordings will use between 4-8GB per hour. Remember that digital tuners capture the compressed stream as it is broadcast, so you have no control over the bitrate. The amount of required disk space will vary with user preference and content, however with disk space readily available for under $0.10/GB, systems should expect to use at least one large hard drive.
You may set up multiple backend machines, and MythTV will handle distributing recording among them just fine. You may however only have one master backend that tells the others what to do.
The jobqueue manages tasks such as commercial flagging and transcoding, as well as offers four slots for user definable tasks. The jobqueue has traditionally been a part of the backend, and each backend will run one jobqueue, however other machines can host a jobqueue with the executable 'mythjobqueue'. With high definition content and digital tuners, frontend playback now requires considerably more power than backend recording. Having the jobqueue detachable from the backend allows a bit more flexibility planning an advanced multi-system MythTV setup.
The frontend is basically the graphical interface that shows you the menus and displays the videos on your screen, so obviously it needs X to be on the same machine. Since it is the interface, this is also likely the best place to install any IR recievers or transcievers you have so that you can use a remote control with MythTV. Because of the way the plugins work, it's also probably the logical place to install an optical drive if you intend to watch DVDs or VCDs with MythTV. What it doesn't need is any particularly large amount of storage space since it doesn't really write much except the cached theme files.
Mythfrontend gets it's configuration information (including where the backends are) from the database so it must be able to talk to the database. It gets information about which tuners are available, as well as any video data it's going to show you, from the backend server so it needs to be able to talk to that as well.
You may have as many frontends as you wish, but understand that the number of them that you can watch different live television programs with will be limited to the number of active tuners you have. If you want to have a frontend in your study, and another frontend in your living room, and you intend to watch a different live program on each, your backend(s) will need at least two tuners installed.
...also known as "where has all my money gone?"
CPUs and RAM
CPU power is very essential for a number of the tasks MythTV performs. While the frontend doesn't really use much more power than is necessary to play a video in full-screen mode and the database really doesn't work all that hard at all, the backend can use literally as much power as you can possibly throw at it. If you plan on doing framegrabbing (see below as to why you should avoid this if you can) you're going to need lots of CPU power, preferably about 1.2Ghz per tuner. Commercial flagging is fairly CPU-intensive, but transcoding really takes the cake since technically it's doing as much work as playing a video plus the work it takes to compress that video all over again.
The frontend and database server don't particularly benefit from a dual-core or multiprocessor system, but the backend can potentially be running many tasks at the same time, and dual-core setups can be very useful for this. What you can't do is split one job between multiple backend machines, but aside from that, more CPU == good, with the absolute lowest acceptable minimum being about 600Mhz for machines with only one (non-framegrabbing) tuner and a frontend playing back standard-definition (a.k.a SD or "normal" TV) content only (high-definition content would be a recipe for failure) and job prioritizing very carefully arranged. Unless you're a Linux guru, stick with the former 1.2Ghz per tuner specification.
MythTV by itself doesn't need a huge amount of RAM, although there are some factors to keep in mind. Most people's setups with everything running on one machine and a single tuner card should be able to get by with a mere 256Mb of RAM. Definitely allocate about 256Mb of RAM per framegrabbing task if you intend to do framegrabbing, although again, a hardware-accelerated tuner card makes the effort required to record quite minimal. Most people will probably find 512Mb of RAM a very comfortable amount of memory for the machine.
Disk storage is going to be the system's life blood. You will be amazed at how quickly your new MythTV box can just gobble up disk space. Standard definition recordings will take between 1-3GB per hour, while high definition recordings will run upwards of 8GB per hour. Depending on how you recorded the video, you may be able to transcode to a higher efficiency format, and/or losslessly remove the commercials. Removing commercials can save up to 30% of the original file space, and transcoding should not be expected to drop the size to less than half of the original without incurring noticeable quality loss. Video requires a lot of throughput compared to other tasks, but it's nowhere near the levels of throughput even older IDE disks can supply, so you needn't worry about needing a RAID striping solution. What you will want is simply lots and lots of disk space for the backend.
The only other serious thing to keep in mind about disk space is what will be used by the database. The amount of space the database is going to need will vary between 128Mb at a bare minimum (someone using no plugins who only has four or five broadcast channels) all the way up to possibly as much as 1Gb of disk space (people with satellite TV, a giant collection of mp3s using MythMusic, and archiving some things into MythVideo). Most people should consider 256Mb~512Mb of space for their database, and it's probably a good idea to make this space into it's own partition to ensure that nothing else (or you) can accidentally fill up the available disk and cause the database to crash and become corrupted beyond repair. Once the database is destroyed, there is no easy way to get the information about what you had recorded back into it without simply restoring a copy of it from a backup you probably didn't make.
MythTV does not rely heavily on the network for anything much except pulling down the program guide information, so if all you have is a on-demand dialup gateway at home, you should be fine. If you go for an advanced configuration with separate frontends and backends, although streaming video across a home network can use a bit of traffic, a plain wired ethernet network (i.e., 10base-T cabling, a.k.a. 10 Mbit) should be work for a single frontend with standard definition content. If you plan on using multiple backends or frontends or streaming HD content, or copying these resulting massive files around your network from one machine to the other, you're probably going to be much happier with fast ethernet (i.e., 100base-T cabling, 100Mbit) and a switch instead of the tired old 10base-T hub. 10mbit equipment is relatively difficult to find anymore, completely replaced by 100mbit equipment in the consumer market. Even gigabit equipment is fairly common, and for streaming HD content to multiple frontends, it is advisable to run at least the backend on gigabit.
Wireless throughput, on the other hand, tends to fluctuate more than most people realize due to all the various and sundry things that can interfere with it, so don't expect 11Mbps 802.11b to handle it without the occasional hiccup. 802.11g or 802.11a (if you can afford it) is somewhat recommended, and should offer enough bandwidth for a single HD stream, but the real problem is consistency of throughput, which radio devices tend to lack. Users are reporting good experience with draft-802.11n equipment, which promises to be more robust against interference, however you still share a limited amount of throughput with all connected machines.
Some of the other pieces you might need would be an optical drive, and of course the ever-present infra-red remote control required for high "spousal acceptance factor".
A DVD burner (even a dual-layer model) installed to the frontend can be used by a new plugin called MythArchive to burn backups of videos you've recorded to DVD in a format that consumer DVD players can play back, and thankfully they're pretty cheap. MythDVD is a plugin that is basically just a DVD player application, and it can make use of a DVD drive as well.
A good remote control is probably what most people would consider to be an absolutely essential piece to add to the frontend. Some tuner cards come with an infra-red receiver element and remote control, but even if yours doesn't you should be able to get a nice generic remote control at department stores, and there are a few places mentioned on the wiki that can sell you a pre-built receiever or transciever on the cheap. Those of you who are planning on trying to record premium content (i.e., content that is normally scambled but gets descrambled for you by the cable box you get for being such a well-paying subscriber) will probably need to consider also purchasing an infra-red transmitter or transciever (one that both sends and receives IR signals) so that the MythTV box can emit the IR signals necessary to tell the cable box to change channels.