Difference between revisions of "Executive Overview"

From MythTV Official Wiki
Jump to: navigation, search
m (Software pieces: Added Database server)
(Change category)
 
(53 intermediate revisions by 9 users not shown)
Line 1: Line 1:
 +
{{User Manual TOC}}
 +
{{UpToDate 0.27}}
 +
 
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.
 
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).
 
 
= Operational Breakdown =
 
= Operational Breakdown =
...or "My God, it's full of pieces!"
+
[[Image:Mythdiagram.png|thumb|200px|right|Operational Illustration]]<sup>''...or "My God, it's full of pieces!"''</sup>
 +
 
 +
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.  The base system also plays video files that have been manually added to the system. There is a plugin 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.
 +
 
 
== Software pieces ==
 
== Software pieces ==
...also known as "the free parts".
+
<sup>''...also known as "the free parts".''</sup>
  
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.  It's important to understand what role each of these pieces plays in order to be able to make correct decisions about what parts to run on which pieces of your equipment.
+
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 which pieces to run on what hardware, and what hardware you might need to purchase.
  
 
=== Database Server ===
 
=== Database Server ===
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.
+
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.  Use the latest or a recent stable version. MythTV requires version 5.0.15 or higher.  Don't get crazy and try using beta or development versions of MySQL unless you're a very experienced programmer and fully intend to take on debugging and patching things to work without any outside help.
  
Work is progressing on porting things to work with Postgres, but at the moment MySQL is the only ''supported'' (and reasonably safe) relational database that worksMySQL 4.1.x is probably "best", but with MythTV 0.20 it became reasonably safe to use MySQL 5.0.x.  Don't get crazy and try using beta or development versions of MySQL (like 5.1.x) or Postgres 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 1-2Gb of disk space (not many people will ever have a database larger than this).  Also, if there's any part of your setup that you'll want to arrange regular backups for, it's the database filesWithout 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.
  
The database server is going to need some disk space to store the actual database information.  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 must be '''only one''' database server involvedIf 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.
  
 
=== Backend Server ===
 
=== Backend Server ===
=== Frontend Server ===
+
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 CPU power, and the backend only needs enough throughput to send content to the frontends.  The backend also runs one Jobqueue (see below), 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).
 +
 
 +
If you use a television service that requires an infrared remote control to change channels (such as Comcast Digital Cable in the U.S.), your back end will need to have an [[IR Blaster]] which points at the cable box's receiver. You will need to set up the [[LIRC]] software (which also supports remote controls for use with the front-end system) to control the IR blaster.
 +
 
 +
The backend is typically where you're going to want to have the bulk of your fixed disk storage.  The amount of required disk space will vary with user preference and content, but with new drives readily available for under $0.033/GB the purchase of new and very large disks should not pose a problem.  Although an external dedicated fileserver isn't out of the question, the backend process is where most of the tons of realtime video data will be coming from so it makes sense to keep the backend process and the bulk of your disks as close together as possible.
 +
 
 +
You may set up multiple backend machines with multiple tuners in each 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.
  
== Hardware pieces ==
+
=== Frontend Client ===
...also known as "where has all my money gone?"
+
The frontend client 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 receivers or transceivers 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.
=== CPUs and RAM ===
 
=== Disk storage ===
 
=== Networking considerations ===
 
  
 +
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 and almost all video data from the backend server, so it needs to be able to talk backends as well.
  
= Various Technical Explanations =
+
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.
...so you don't let the nice salesmen talk you into buying something gold-plated ''and'' obsolete.
 
== Issues for recording ==
 
=== Framebuffers and firewire and hardware compression, oh my! ===
 
There are three basic ways for MythTV to record broadcasted content, and which ones are usable is tied to how the user gets their TV signal in the first place.  The first (and probably least desireable) is a technique called "framegrabbing", the second is over a firewire connection (ideal but not widely applicable), and the third (and least troublesome) is from a tuner card that uses hardware-accellerated video compression.
 
  
Framegrabbing is what you're stuck with if your tuner card is one of the older (and/or simpler) tuner cards made that uses a Brooktree chip called the Bt848, Bt878, or Bt878a (although there are a few other variants). These cards are the cheapest type of tuner cards one can get, but this inexpensiveness has it's own hidden price. Framegrabbing (in almost layman's terms) is when the tuner card is given a (nearly literal) window of memory used by your video card to paint the recieved video image into in realtime. The CPU has to "grab" each frame as it appears and then copy it to the software compression codec in order to compress the data so that it doesn't take up absolutely ludicrous amounts of disk space.  The audio usually has to be fed through the line-level input on the sound card to be recorded, although there are some cards that support sending audio directly to the CPU through DMA transfers.  These cards are excellent for just ''watching'' live television broadcasts, but the task of grabbing the images and audio and compressing it in realtime makes framegrabbing a ''very'' CPU-intensive task.  Generally an SD broadcast requires at least 1Ghz of processing power and about 256Mb of RAM in the machine to record just ''one'' stream.
+
== Hardware pieces ==
 +
<sup>''...also known as "where has all my money gone?"''</sup>
 +
=== CPUs and RAM ===
  
Firewire is one of the primary transport mediums used for digital cameras and other forms of digital video transferIf you are a subscriber of HD digital cable in the US, there's a good chance the receiver you got from the cable company has a firewire port on it. If it doesn't ask them for one and you'll likely get it (FCC mandate).  Depending on who your cable provider is, you ''may'' be able to get the video you're watching on the receiver to stream from your cable box to your MythTV box over the firewire cable in it's raw, compressed form (which would be great)At the very least, you should be able to use the firewire connection to make the receiver box change channels (which is less problematic than using an IR blaster and LIRC).  Recording video over firewire doesn't require much CPU at all, but with some channels it may be a bit like "drinking from the fire hose" if your machine is underpowered.
+
CPU power is very essential for a number of the tasks MythTV performsWhile 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 to do transcoding or commercial flagging. If you plan on doing framegrabbing (this is only applicable to analog tuners without hardware encoders, which are not likely in any modern system) you're going to need ''lots'' of CPU power, preferably about 1.2Ghz per tunerCommercial 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.
  
Video tuner cards with hardware-accellerated compression that are ''affordable'' are somewhat new to the personal computer market, but they're absolutely wonderful now that they're here.  What this means is that the tuner card itself handles the "heavy lifting" of compressing the video signal down to an MPEG or XviD stream so your computer doesn't have to.  Recording video with these isn't really much more CPU-intensive than just copying a file.  If your computer is capable of playing back an SD video in fullscreen without skipping or dropping frames, then it's probably got enough power to handle one of these cardsThe most common are the Hauppauge PVR-xxx series cards, which are detailed elsewhere on this site.
+
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 arrangedUnless you're a Linux guru, stick with the former 1.2Ghz per tuner specification.
  
== Issues for playback ==
+
MythTV by itself doesn't need a huge amount of RAM, although there are some factors to keep in mindMost 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 RAMDefinitely 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 minimalMost people will probably find 512Mb of RAM a very comfortable amount of memory for the machine.
=== Widescreen or SD (standard definition) ===
 
Thankfully, dealing with whether or not you have a widescreen (16:9 aspect) display or a normal (4:3 aspect) display is something that only X (Xorg or XFree86, either will do) only has to deal withFor the most part it's a simple matter of configuring X to use the display at it's ''native resolution'' as if it were a normal monitorIf you have a highly expensive display which does 1920x1080 resolution (1080i/p with no downsampling) then that's the resolution you tell X you want to use.  If you're using a widescreen LCD monitor that does 720i/p (without downsampling) and has a native resolution of 1280x768, then you configure X to use the display at that resolution.  With ''some'' widescreens (and some video cards) that X can't quite figure out on it's own, the user may have to manually generate a modeline (or search the wiki for one) that tells X how to use the display, but this  is ''usually'' not necessaryIn almost every case, the video card (possibly with the help of accellerated drivers) and MythTV will be capable of upsampling (expanding) or downsampling (shrinking) the images to fit the display exactly.  You'll still get "letterboxing" if you watch a widescreen video on a standard (4:3) display, of course but the fewer resolution changes your video has to be put through before appearing on your screen, the better.
 
  
=== HDMI, DVI, VGA, S-Video, Component, and Composite Output ===
+
=== Disk storage ===
The type of output your video card can do, and the type of inputs your display device can handle are primarily what dictates what you should use to connect themFrom highest- to lowest-quality, the order of consideration is: HDMI, DVI, VGA, S-Video, Composite.
+
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 typically use 1-3GB ''per hour'', and high definition recordings will use between 4-8GB per hour.  Depending on how you recorded the video, you may be able to transcode to a higher efficiency format. Transcoding can save considerable space, depending on the amount of compression already in use. Transcoded to x264 HD video uses 1-3GB per hour with no  noticeable quality loss when you use appropriate settingsVideo 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.
  
HDMI is a digital connection primarily seen on high-end home theater displaysIt also incorporates some technology to thwart naughty video-pirates, but this mostly stays out of our way (for now).  If your television and your video card both support this, then it's probably what you'll want to useIt's likely that any display which has an HDMI input also supports DVI input, so you don't need to rush out in a mad buying frenzy to get a new video card if your video card already supports DVI output--the quality difference between them isn't likely to bother you.
+
The only other serious thing to keep in mind about disk space is what will be used by the databaseThe 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 repairOnce 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. This is why a weekly backup of the database is an essential component of the system.
  
DVI is another type of digital connection which is somewhat more common than HDMIHDMI and DVI connectors look rather similar (in that they're obviously not the 15-pin DIN connector of VGA) but don't get them confused. Most LCD/TFT panel displays support DVI input, and most newer video cards will have a DVI output (some will have two).
+
=== Networking considerations ===
 +
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 fineIf 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 fast ethernet network (i.e., 100base-T cabling, 100Mbit) should work for several frontends with standard or high definition content.  If you plan on using multiple backends or copying these resulting massive files around your network from one machine to the other, you're probably going to be much happier with ''Gigabit ethernet'' (i.e., Cat5E or Cat6 cabling, 1000Mbit) and a switch. There are also tuners that are network attached and if you are using one of these then Gigabit ethernet is the way to go. If you are setting up a new network, definitely you should got with Gigabit throughout, since the cost is not much more than 100Mbit.
  
VGA is the "normal" monitor cable everyone's used to seeing on computers and monitorsA great many of the LCD TVs currently being manufactured in the US are intended to be dual-purposed as computer monitors and will have a VGA input (and possibly DVI as well), and nearly all (some are coming DVI-only now) computer monitors being sold as computer monitors will accept VGA input. Your video card will almost certainly support VGA output, and even if it only has one (or two) DVI output on it, it should have come with a little adapter that will allow you to use it with the more common VGA display.
+
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 hiccup802.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 802.11n equipment, which promises to be more robust against interference, however you still share a limited amount of throughput with all connected machines. Do not expect to get the advertized speeds with wireless and do not expect to run a remote frontend with HD on a wireless network.  
  
S-Video is a multiple pin, round connector type that carries the chroma and luma (color and brightness) parts of the video signal over separate wires, which usually means a very good signal.  It looks a little bit like a PS/2 mouse connector, but with more pins.  Many, many televisions support S-video input.  The cables are reasonably inexpensive, and can be up to fifteen feet long without experiencing notable signal loss.  Word of warning: Some video cards have what looks very much like an S-Video output, but has a few more pins involved and is '''not''' an S-Video output.  These cards will have come with a "breakout box" which will have a number of other connectors on it which often include an actual S-video output, as well as component outputs, and sometimes a composite output as well.  Don't get confused and try to force an S-Video cable directly into these, because bent pins really suck.
+
A better option than wireless is powerline network adapters. Like wireless you do not get the advertised speed, but an adapter that advertises 500Mbit speeds can deliver 50Mbit speeds and successfully work with HD.  
  
Component video splits the video signal up into it's three "component" parts, the red signal, the green signal, and the blue signal and sends them over the familiar RCA connections.  You can spot these pretty easily because they'll usually be three RCA connectors colored respectively red, green, and blue.  This is used by some "studio" monitors, some ''very'' expensive theater displays (quite often projection screens), as well as some SUN-type displays and so forth.  It's only listed after S-Video because it's not that often you'll come across displays that use this.
+
=== Other hardware ===
 +
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".
  
Composite video is probably the least desirable connector type of the lot.  It's the type of output most video games use, and practically every display supports at least this if you aren't going to have to use an RF modulator with it.  It will be a single RCA connector which should be yellow.  The other two RCA connections commonly found with it will be white and red, which are the left and right audio channels respectively(Remember, '''r'''ight and '''r'''ed start with the same letter.)  Some of the older nVidia cards have only a composite video connector for TV output.  To use the TV output on these cards you will need the nvtv driver as well as nVidia's binary driver.  For ''no other nVidia cards'' do you need nvtv so don't put yourself through that hassle by mistaking it for something you need if your nVidia card has an S-video output.
+
A DVD burner (even a dual-layer model) installed to the frontend can be used by a 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 cheapA DVD player application is built in, 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 receiver or transceiver on the cheap.  Those of you who are planning on trying to record premium content (i.e., content that is normally scrambled 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 transceiver (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.
  
=== Audio Output ===
+
[[Category:Knowledge Base]]
...or "How I learned to like stereo all over again".
 

Latest revision as of 16:31, 10 July 2015

Software-update-available.png This page is up-to-date as of MythTV version 0.27.6, the current release is 34.0

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.

Operational Breakdown

Operational Illustration
...or "My God, it's full of pieces!"

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. The base system also plays video files that have been manually added to the system. There is a plugin 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.

Software pieces

...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 which pieces to run on what hardware, and what hardware you might need to purchase.

Database Server

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. Use the latest or a recent stable version. MythTV requires version 5.0.15 or higher. Don't get crazy and try using beta or development versions of MySQL unless you're a very experienced programmer and fully intend to take on debugging and patching things to work without any outside help.

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 1-2Gb of disk space (not many people will ever have a database larger than 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.

Unlike the other components of MythTV, there must 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.

Backend Server

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 CPU power, and the backend only needs enough throughput to send content to the frontends. The backend also runs one Jobqueue (see below), 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).

If you use a television service that requires an infrared remote control to change channels (such as Comcast Digital Cable in the U.S.), your back end will need to have an IR Blaster which points at the cable box's receiver. You will need to set up the LIRC software (which also supports remote controls for use with the front-end system) to control the IR blaster.

The backend is typically where you're going to want to have the bulk of your fixed disk storage. The amount of required disk space will vary with user preference and content, but with new drives readily available for under $0.033/GB the purchase of new and very large disks should not pose a problem. Although an external dedicated fileserver isn't out of the question, the backend process is where most of the tons of realtime video data will be coming from so it makes sense to keep the backend process and the bulk of your disks as close together as possible.

You may set up multiple backend machines with multiple tuners in each 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.

Frontend Client

The frontend client 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 receivers or transceivers 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 and almost all video data from the backend server, so it needs to be able to talk backends 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.

Hardware pieces

...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 to do transcoding or commercial flagging. If you plan on doing framegrabbing (this is only applicable to analog tuners without hardware encoders, which are not likely in any modern system) 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

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 typically use 1-3GB per hour, and high definition recordings will use between 4-8GB per hour. Depending on how you recorded the video, you may be able to transcode to a higher efficiency format. Transcoding can save considerable space, depending on the amount of compression already in use. Transcoded to x264 HD video uses 1-3GB per hour with no noticeable quality loss when you use appropriate settings. 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. This is why a weekly backup of the database is an essential component of the system.

Networking considerations

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 fast ethernet network (i.e., 100base-T cabling, 100Mbit) should work for several frontends with standard or high definition content. If you plan on using multiple backends or copying these resulting massive files around your network from one machine to the other, you're probably going to be much happier with Gigabit ethernet (i.e., Cat5E or Cat6 cabling, 1000Mbit) and a switch. There are also tuners that are network attached and if you are using one of these then Gigabit ethernet is the way to go. If you are setting up a new network, definitely you should got with Gigabit throughout, since the cost is not much more than 100Mbit.

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 802.11n equipment, which promises to be more robust against interference, however you still share a limited amount of throughput with all connected machines. Do not expect to get the advertized speeds with wireless and do not expect to run a remote frontend with HD on a wireless network.

A better option than wireless is powerline network adapters. Like wireless you do not get the advertised speed, but an adapter that advertises 500Mbit speeds can deliver 50Mbit speeds and successfully work with HD.

Other hardware

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 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. A DVD player application is built in, 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 receiver or transceiver on the cheap. Those of you who are planning on trying to record premium content (i.e., content that is normally scrambled 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 transceiver (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.