Koolu as MythTV frontend suggestions

[Ben Scott]

On Jan 29, 2008 8:50 PM, Ted Roche <tedroche at tedroche.com> wrote:
> Got my Koolu ... MythTV front end ...

  As I recall, the opinion of some MythTV experts was that the Koolu
was somewhat underpowered to be doing real-time decoding of compressed
video.  The Koolu is optimized for lower power, not performance.
While I'm sure, with sufficient hacking, it could be made to work, the
extent of that hacking may be well beyond the point of diminishing
returns.  (Think "rewrite MythTV, X, and the kernel".)

  No harm in trying, of course.  I just wanted to warn you up front.  :)

> I was thinking I'd start with 'top' and determine if the CPU's overloaded ...

  Also check memory usage.  Send capital M to top while running to
sort by memory, or use free(1).

  vmstat(1) and iostat(1) are the standard issue *nix tools for
checking all things performance, but I think I've forgotten everything
I ever knew about them (which wasn't much, and was quite out-of-date
anyway).

> I suspect GNOME is overkill  ...

  Absolutely.

  If literally *all* you're doing is running a MythTV front end, it
should be possible to do just that: Run mythfrontend as the only X
client, eliminating even the window manager.  As a first guess, try
replacing $HOME/.Xclients with the following:

	#! /bin/bash
	/usr/bin/mythfrontend

  I'd suggest creating a separate user account just for the purposes
of running the MythTV front end, and doing that for the above.  That
way, you can keep another user account around for trouble-shooting,
etc.  (Running a lightweight desktop like Xfce, of course.  ;-)  )

> I'm also planning on reviewing the xorg.conf and see if there are
> things there worth tweaking.

  Worth trying.  I have an amd(4) man page on my FC6 box (xorg 7.1).
It doesn't look overly promising, but maybe the newer releases are
better, or the man page is incomplete.  Also see if that chip/driver
supports DRI and if your kernel modules for that are loaded.

> Finally and reluctantly, I'll do some overdue housekeeping on the
> network.

  Can't hurt, but if the network was the problem you'd likely see it
for all your MythTV front ends (and I take it you don't).  Network
issues will generally keep data from getting to the destination, so
slow boxes usually don't get slower if the network is slow.  There are
always exceptions, though, so it's worth a shot, and is likely of good
benefit anyway.

  Ideally, find someone who has a cable analyizer and borrow it, and
certifiy all your links to Cat 5 or better.  (A *real* cable
analyizer.  They cost thousands of dollars new.  Not one of the $100
jobs that are just glorified continuity testers.)

> I'm guessing this can be worked out with a series of trial-and-error,
> copy-a-big-file from A-to-B tests to pinpoint the problem.

  There are better ways than a big file copy, although trial-and-error
are still involved.  (We in the biz like to call it "fault isolation".
 We can charge more for that.)

  Even the lowly ping(1) command can yield insight.  The -i and -s
options (interval and size) can be used to test how network load
impacts performance.  If your ping does name lookups by default,
always use -n (to eliminate name service as a cause of confusion).
For the ultimate stress test, try "ping -n -f -s 65507".  (Note that
I've actually killed hardware with that.  But then, that transceiver
likely needed to be replaced anyway.)

  For more sophisticated tests, try ttcp, which benchmarks TCP and UDP
performance.  Google finds many versions.

  Good luck!  May the Force be with you!

-- Ben