[mythtv-users] Good system design documentation?

Michael T. Dean mtdean at thirdcontact.com
Fri Jun 3 22:18:00 UTC 2005

Steve Tate wrote:

> Is there a document available that goes through the various components
> of a mythtv system and talks about various system design tradeoffs?

Not yet, but Robert Kulagowski is extremely good at incorporating 
patches/changes/additions into the official documentation.  Perhaps once 
you get the information you need, you can help improve the docs.

> I've been frustrated looking at the official documentation, which is
> in FAQ format, and seems to assume people understand the basic mythtv
> architecture going in.  The docs talk about frontends and backends as
> if everyone naturally knows that they are, but never actually explains
> this.
> What I've gleaned is what defines a frontend is the ability to play
> things and what defines a backend is the ability to record.

Perfect.  That's exactly right.

> ...
> For instance, if I have a EPIA-based box hooked up to the TV with a
> tuner card in it, it can both play and record -- that makes it a
> frontend and a backend, right?


> Can it be diskless?


> In other words, could I have a "tunerless" backend,

Without a tuner, the computer is not a Myth backend.  Without a display 
(TV, monitor, etc.), it's not a Myth frontend.

> consisting of my main home network
> server, and a "diskless" frontend/backend at the TV?

In this case, you would have one frontend/backend combo and one NFS 
server (that's not a Myth box and has no need to have MythTV 
installed).  If your main server also has MySQL on it, it's a MySQL 
server.  If it has Apache httpd on it, it's a web server.  Note that the 
MySQL server and the Apache server need not be on a Myth machine to be 
used with Myth.  If you did install MythTV on the server, you could use 
it for things like remote commercial flagging or (if they've finished it 
up, yet) remote transcoding, but chances are

> I could put the
> PVR-250 in the file server, of course, but does that mean that I'm
> consuming network bandwidth with a video stream just to watch live TV

Yes.  Data has to travel from the tuner to the Myth frontend.  If the 
tuner is on a different machine, it can only get there via the network.

> (which is why I'd want the tuner in the frontend box in the first
> place)?  And then I'd have problems using the remote control from the
> PVR-250 as well...   I'd really like a RAM-based ringbuffer for live
> TV, so that doesn't hit the network at all,

You could do the same with a HDD-based ring buffer.  Remember that 
MPEG-2 video will take up at least a GiB/hr, so you'd have to have a 
512MB area of memory dedicated to the LiveTV Ring Buffer (i.e. above and 
beyond the memory required to run the system) to get a half hour 
buffer.  Besides saving a little wear on a HDD, the RAM buffer wouldn't 
provide any benefits (bandwidth is not a limitation for video playback).

> and then the ability to
> stream pre-recorded video from the file server to the frontend.  Is
> that something that can be done?

You can specify a different location for the LiveTV buffer and for the 
recordings.  So, you could use the fileserver to store your recordings 
and use a local hard drive for the ring buffer.  Of course, that is if 
you even use LiveTV after setting up your Myth box.

Also, Myth will stream content if it has to, but most people set up a 
network filesystem and mount the filesystem on each of their frontends.  
If you configure your Myth set up this way, there's no need to stream 
the video--it can be read directly from the (network) filesystem.

Remember, though, if your recordings are stored on the file server, 
you'll consume network bandwidth as you record them and as you play them 
back (i.e. if watching while recording, you'll consume 2x the recording 
bandwidth).  Although it's not that much bandwidth (i.e. 2500kbps 
bitrate works very well for me, so recording while watching would be 
about 5Mbps).  Same applies with multiple tuners and with commercial 
flagging.  In each case, the data has to be transferred across the network.

> Anyway, maybe some of those questions are confused, but it's mainly
> because I have a very poor mental image of the mythtv architecture,
> and can't find any documentation that explains this.  Does anyone know
> of something decent that's out there for me to read?

IMHO, the best way to learn is to set up your system.  I doubt that 
anyone on the list set up their dream system on the first try, but 
that's what makes Myth so great--there's always room to improve your 
configuration and since it's "free" ( http://www.fsf.org/ ), you're free 
to modify it as much as you like.  And, the funny thing about the 
"dream" Myth system is that it's a moving target.  The closer you get to 
your dream system, the more you learn about Myth.  The more you learn 
about Myth, the more ways you can imagine to improve your 
configuration.  The more ways you can imagine to imrpove the 
configuration, the farther you get from your dream system...  :)

I set up one Myth box as a test system and used what I learned when 
setting it up to make a second system even better.  My main production 
box has gone through many different changes throughout it's 
lifetime--from all local hard drives to network filesystem to all local 
hard drives and that's just one example.  If you approach a Myth box as 
a way to learn, it's well worth the amount of time it takes.  If you 
just want a digital video recorder up and running really quickly so you 
can record every episode of Lost and you don't particularly want to 
spend time playing with it, you might be better off with a TiVo.



More information about the mythtv-users mailing list