Mailing List Archive

Client-Server hardware arch questions?
Hello, I am a Myth newbie so bear with me if some of the questions are silly.

I am a 3+ year TiVo user and recently me and a friend of mine decided to play with the free linux pvrs out there. My friend picked freevo and I went with MythTV. The reason for my choice is the client server architecture - the potential of it just awed me. This is exactly the type of thing I always wanted.

So I wanted to understand how this works and a good way to put together a hardware platform to make this most usefull. What I am seeing in ideal world is this:

A heavy use server(or several) with PVR250 (or several) and a lot of hard drive space (maybe USB2/Firewire for expanding). The server will run backend part only, and maybe not even have a sound card.

Several lightweight frontend machines which are pretty much set-tops:
* Diskless (they can boot off the server or flash)
* Fanless (or as close to silent as possible)
* Small
* Good Quality Video Out (Composite/S-Video/maybe also a VGA-1080i converter for my Wega)
* Good Quality Audio Out (Option for optical out?)
* Contain DVD/CD drive for watching DVD/*VCD's, listening/ripping music CD's, Listening to MP3-CD's.

So here are the questions:

* How does the Myth frontend talk to backend? Is the video (audio, still picture, etc) transmitted in-band or do I need to NFS export the directory containing the common files? Is the media stream using TCP or UDP?

* What are the bandwidth requirements for connecting FE to BE? My calculations using 2GB per hour as top end PVR250 recording puts it at about 5 Mbit/s sustained w/o overhead(which pretty much excludes 802.11b, but a/g or FastEthernet may work) Are these numbers anywhere near reality?

* I assume the decoding is done on the front end, are there any hardware MPEG accellerators that can be used to offload decoding on the front end? I mean something a bit more lightweight than PVR250 (which is what I have now) - I only need to decode, not encode. Would the old DVD MPEG cards work? Any of them supported under linux?

* When you have multiple backends, do they communicate to determine optimal recording capabilities? Can you set priorities for recuring recordings to auto-determine what is recorded in case of conflict?

* When you have multiple backends, are they seen as one by the frontend?

* Where do the "plugins" run? On the backend? frontend? both?

* How many frontends can a backend support?

* What is the best cost effective frontend (as described above) hardware?

* Is there a possibility of (imaginary right now) "MythDVD" plugin allowing DVD playback running on frontend only?

* Am I asking way too many questions?

-Max
Re: Client-Server hardware arch questions? [ In reply to ]
On Tuesday 13 May 2003 12:45 pm, Max wrote:
> So here are the questions:
>
> * How does the Myth frontend talk to backend? Is the video (audio, still
> picture, etc) transmitted in-band or do I need to NFS export the directory
> containing the common files? Is the media stream using TCP or UDP?

You can do both, actually. The backend will stream the file on the fly to the
frontend for playback using TCP, but if you NFS mount the the recording
directories so they're in the same place on the frontends as they are on the
backend, it'll use that instead. Currently, only TV recordings are
frontend/backend aware, but I hope to change that sometime after the next
release.

> * What are the bandwidth requirements for connecting FE to BE? My
> calculations using 2GB per hour as top end PVR250 recording puts it at
> about 5 Mbit/s sustained w/o overhead(which pretty much excludes 802.11b,
> but a/g or FastEthernet may work) Are these numbers anywhere near reality?

Yeah, that's close. 4GB/hour, though, for top end PVR250 recording.

> * I assume the decoding is done on the front end, are there any hardware
> MPEG accellerators that can be used to offload decoding on the front end? I
> mean something a bit more lightweight than PVR250 (which is what I have
> now) - I only need to decode, not encode. Would the old DVD MPEG cards
> work? Any of them supported under linux?

My p3-550 decodes full-resolution (720x480) files produced by the pvr-250 just
fine, so you may not even need/want a hardware decoder. The major issue of
using those cards is that you need to have _everything_ shown be in mpeg
format -- including the non-video user interfaces.

> * When you have multiple backends, do they communicate to determine optimal
> recording capabilities? Can you set priorities for recuring recordings to
> auto-determine what is recorded in case of conflict?

One backend is designated the 'master' and tells all the other ones what to
record. You can't set priorities, no, but you can tell it what you prefer to
record in case of a conflict. A couple people have mentioned they may work
on implementing actual recording priorities, though.

> * When you have multiple backends, are they seen as one by the frontend?

Yup. All communication from the frontend(s) goes to the master backend.

> * Where do the "plugins" run? On the backend? frontend? both?

Frontend.

> * How many frontends can a backend support?

No idea. Most I've ever run simultaneously with off of a single backend was 3
(2 live-tv sessions, one pre-recorded playback). I don't believe there's any
hard limit in the code.

> * Is there a possibility of (imaginary right now) "MythDVD" plugin allowing
> DVD playback running on frontend only?

With the DVD drive on the frontend? Sure, that's easy -- you can add a button
to the main frontend menu that starts up a dvd player app, or you can add a
link in mythvideo to do the same.

Isaac
Re: Client-Server hardware arch questions? [ In reply to ]
Isaac Richards wrote:

>On Tuesday 13 May 2003 12:45 pm, Max wrote:
>
>
>>So here are the questions:
>>
>>* How does the Myth frontend talk to backend? Is the video (audio, still
>>picture, etc) transmitted in-band or do I need to NFS export the directory
>>containing the common files? Is the media stream using TCP or UDP?
>>
>>
>
>You can do both, actually. The backend will stream the file on the fly to the
>frontend for playback using TCP, but if you NFS mount the the recording
>directories so they're in the same place on the frontends as they are on the
>backend, it'll use that instead. Currently, only TV recordings are
>frontend/backend aware, but I hope to change that sometime after the next
>release.
>
>

I've been curious about this as well.. So is it possible to have a beefy
backend comp with two or more video cards, lots of disk space, etc,
and then have "thin clients" for the TV frontends, with the only real
requirements being TV-out? For example, the frontends would only need
to have 100mbit ethernet, a vid card w/ tv out, and a tiny hardrive (or
ramdisk?) for the OS, right? If so, that would be incredible!
Re: Client-Server hardware arch questions? [ In reply to ]
On Tuesday 13 May 2003 10:42 pm, Ben Davis wrote:
> >You can do both, actually. The backend will stream the file on the fly to
> > the frontend for playback using TCP, but if you NFS mount the the
> > recording directories so they're in the same place on the frontends as
> > they are on the backend, it'll use that instead. Currently, only TV
> > recordings are frontend/backend aware, but I hope to change that sometime
> > after the next release.
>
> I've been curious about this as well.. So is it possible to have a beefy
> backend comp with two or more video cards, lots of disk space, etc,
> and then have "thin clients" for the TV frontends, with the only real
> requirements being TV-out? For example, the frontends would only need
> to have 100mbit ethernet, a vid card w/ tv out, and a tiny hardrive (or
> ramdisk?) for the OS, right? If so, that would be incredible!

Yup. That was the whole point of the multi-month long rewrite of the
internals for the 0.8 release =) Remote frontends are incredibly easy to
setup, too. All you have to do (beyond having a working linux install, etc)
is to compile mythtv, edit mysql.txt to point to the mysql server that it's
sharing with the backends, and run mythfrontend. Everything else is done
totally automatically.

Isaac