[mythtv-users] Babelbox: A potentially useful new low-cost frontend?

[Luke Rosenthal]

> it's close. The major delays are caused by heavy network traffic (Opening
> "Recorded programs" (1.5 sec) or MythVideo (3
> sec) are the main problem areas, and MythVideo I use the FileSystem
> Gallery view, hence the slowness over the NFS link)

I only ever use "recorded programs", and this is local on the same box. 
No, the box is not heavily loaded when browsing recorded programs - I've
got a laptop next to me running top, and I can see Xorg come up consume
about 50% CPU, but never more.  Mysql never goes above about 10%.  But at
this point mythfrontend is painfully slow to respond to keystrokes - at
least a second per keystroke.  Not exactly useful when you have a few
recordings to sort through.

I have a hunch it's something other than CPU or system resources.  I don't
have lirc set up yet - slowly working my way thru other issues first - is
it possible that mythfrontend is waiting for another keypress?  Waiting
for some escape sequence to be closed out, or terminated?  Or waiting for
something else to timeout?  Even when mythfrontend is grindingly slow, the
rest of the system is quite responsive to other tasks (eg running a find,
viewing a manpage, logging in/out via ssh).

> Are you using the OpenGL painter or the QT painter? Is your MySQL box
> heavily loaded? Do you have Query Tracing switched on? Have you enabled
> DMA in your HDParm config?

I'm using the QT painter.  Would this make a big difference to the way the
menus run?  Would running OpenGL be possible with an old Geforce MX420? 
Am I asking too much of an old P4 2gHz (400mHz FSB) and this graphics
adapter?

Mysql is not doing anything other than serve myth, and is local to the
box, so no.  It never consumes more than about 10% CPU.

Couldn't find anything regarding Query Tracing in the wiki - is this a
myth feature or a mysql feature?  I've run optimize_mythdb.pl, but it made
no noticeable difference.

HDparm stats:

/dev/sda:
 Timing buffered disk reads:  196 MB in  3.03 seconds =  64.72 MB/sec

/dev/sda:
 Timing cached reads:   1200 MB in  2.00 seconds = 599.42 MB/sec

Issuing the command "hdparm -c1 -d1 -X66 /dev/sda" yields:

/dev/sda:
 setting 32-bit IO_support flag to 1
 HDIO_SET_32BIT failed: Invalid argument
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Inappropriate ioctl for device
 setting xfermode to 66 (UltraDMA mode2)
 HDIO_DRIVE_CMD(setxfermode) failed: Input/output error
 IO_support   =  0 (default 16-bit)

Is it even possible to do this on SATA disks?

Cheers,
Luke