[mythtv-users] setup fails

Declan Shanaghy declanshanaghy at yahoo.com
Fri Feb 14 19:11:18 UTC 2003


Aaron Stewart wrote:
> I dunno.. It seems like network transfer of data is adding another level
> of complexity that could be avoided, but if sound dampening is
> necessary, then it's a necessary evil :).
> 
> My understanding was that an uncompressed mpeg2 stream ran at
> 18mbits/sec, which translates to:
> 
> send->18mbit
> recv<-18mbit
> buffer->18mbit (for delayed playback)
> 
> Means that you're using about half of a 100baseTX connection (depends on
> the card.. duplex notwithstanding).
> 
> I might be making all this up.. It's rather late at night..

Sure. I'll call you on that ;-). Proposing that there need to
be 3 18mbit streams is an amazing fabrication and you still
only say that's half the bandwidth. Still you did a good job
of making all this up 8-).

Send AND recv? I assumed frontends meant "mythfrontend"
with no tuner. If you had a diskless machine with a tuner
you could have data going in both directions. But if you get
a tuner card, it obviously makes more sense to put it in the
machine with the disk.

Buffer? You are watching one recording. You can call it
recv or buffer but not both (nice try ;-)!

Uncompressed? Running mythfrontend on a different machine
than the backend pulls the compressed data over the net.
Even if you use NFS, the files are compressed and decoded
locally. MythTV decoding is surprisingly lightweight.
If your recordings are 1.5GB/hour that's still less than
.5MB/sec. That's less than 5mbit leaving 95mbit idle net
with nothing to do.

If a 100mb net can't keep up, something else must be
terribly wrong. I've tested running a remote frontend
over phone net (PNA 2.0) and even that worked for medium
resolution recordings (however, I'm not recommending phone
net as a solution ;-).

--  bjm






More information about the mythtv-users mailing list