Re: Straw Poll - MythTV machine spec.

[Kim Wall <kim@xxxxxxxxxxxxxxxxxx>]

Stuart Grimshaw wrote:
> Just a quick thread to gather what spec PC's people are using with
> MythTV & what you perceive the performance to be ...

Backend/Frontend feeding distribution[0] system via RF modulator:

Duron 900 on an early DDR Asus motherboard with onboard sound, PVR-250=20
fed from Thompson freeview box, 512M of ram, 200gig drive for video,=20
40gig drive for system and DVD mastering.  Nvidia TNT2 card with no TV=20
output feeding VGA-composite converter.  DVDRW drive.  Plan to add a DVB=20
card as soon as DVB subtitling is incorporated into the main build.  In=20
a cheap 4U rackmount case with some noisy but effective fans.  Running a=20
Knoppmyth based install of 0.18.


Frontend feeding main TV via S-video:

Duron 700 (fitted with massively overspecced heatsink with 80mm fan at=20
low speed) in cheap PCChips motherboard with onboard sound, 256 meg of=20
ram, some 4 or 6 gig HD I had lying around (plan to go diskless when I=20
get round to setting that up), and cheap GEforce MX4000 card doing=20
S-video flawlessly with the binary driver.  No DVD drive at present -=20
though plan to add one soon - and stuck in a wholly inappropriate=20
full-tower case wedged on its side under the TV.


Performance isn't really an issue with the frontend... it takes a couple=20
of minutes to boot, and is fast enough to play the video[1] (and the odd=20
game of tuxracer) without problems.  I'm planning to acquire a more=20
suitable case and quieter PSU for it, but the noise level is more or=20
less acceptable, and aesthetics aren't a big deal due to SWMBO being as=20
big a geek as I am and a postgraduate student budget.

The backend encodes MPEG2 in hardware, so can record with minimal load=20
(I briefly experimented with the ancient WinTV framegrabber card I have=20
in my desktop, but the 900MHz duron couldn't do live TV without=20
stuttering).  As you would expect, it can do live TV without problems,=20
although playback can stutter when mysql is working hard during=20
mythfilldatabase runs (this is configured to happen at a time when we're=20
unlikely to be using the backend to watch TV).  I have transcoding to=20
MPEG4 configured in one of the recording profiles to reduce the filesize=20
by about 50% with a reasonable loss in quality (some artefacts visible=20
on the main TV or on a computer, but not usually once its been through=20
the RF system - better than VCD), which I use for programmes I'm not too=20
concerned about the quality of.  Transcoding takes maybe twice the=20
runtime of the programme.  Commercial flagging (for what it's worth[2])=20
takes place in almost realtime.

So yeah, this probably represents a sane minimum spec in terms of actual=20
computing power, though with hardware encoding a backend-only machine=20
could probably get away with a lot less.  I ran the backend with just=20
the 40gig disk for a month or so, which was a bit tight, but still a=20
couple of orders of magnitude more useful than a VCR.  As you can tell,=20
my myth setup was largely cobbled together around parts I had spare, so=20
not necessarily ideal for the purpose.  However it works amazingly well,=20
with the only real problems I've had being related to innacurate=20
listings, a dodgy motherboard in the backend losing its CMOS settings=20
and forgetting to respond to wake-on-lan[3] and the freeview box=20
crashing and getting stuck on one channel[4].


kim.


[0] Well, telly and TV card in study, and small telly in bedroom via=20
wedged-under-doors coax.  The joy of rented houses.

[1] Over a 100base wired network, though worked fine through a 10base=20
hub, too.

[2] I find it works reasonably well on Ch5 and ITV.  Hopeless on Channel=20
4, which is of course where most of the programmes-with-commercials=20
worth recording are.

[3] The backend shuts itself down when idle to save power.  It is woken=20
by a pre-arranged (as part of the shutdown sequence) wake-on-lan packet=20
from the always on file/email server when it needs to record something,=20
or a wake-on-lan packet from the frontend as part of its boot sequence.

[4] I've since cured this by powering the freeview box via a relay=20
operated by the +12V line in the backend's power supply.  Saves power=20
and reboots the box at least once a day.