[mythtv-users] combined HD frontend/backend on P4 3.2Ghz

[Leighton Brough]

> Leighton, what distro are you using and what if any tweaks did you do?
> I'm running Gentoo and have run it for quite a while, but I don't know
> if compiler flags will make any difference. I would love to know what
> you've done since I have no desire to enter another upgrade cycle.
> TIA
> Ali
>   
Hi Ali,

I'm using ArchLinux, with the standard 2.6.18-1 kernel (which now 
includes SMP for HT with my P4). I haven't needed to build a custom 
kernel, as the standard Arch config has everything I need already turned 
on. I built mythtv from source using the --enable-proc-opt option, but 
otherwise all the software on the box is installed from packages. 
ArchLinux packages are built for i686. SMP and building myth with 
optimisation for my processor probably help performance, but I doubt my 
choice of distro matters much (except for the fact that I've found it a 
very painless choice for this application). With Gentoo I guess all your 
software would be even more optimised.

Tweaks and config wise, here's what I'm doing:

The frontend playback settings are:
- Kernel deiniterlacing (I mentioned bob above, but forgot I changed 
back to this a while ago because the jittery OSD annoyed me)
- Real-time threads (make sure you check the frontend log for "Using 
realtime priority" to see this is working - changes to your 
/etc/security/limits.conf may be needed).
- Extra audio buffering (I need this for just one HD OTA channel, which 
otherwise drops the audio every few seconds)

I'm using the RTC method for timing, (i.e. "echo 1024 > 
/proc/sys/dev/rtc/max-user-freq" then check the frontend log for "Video 
timing method: RTC") rather than OpenGL vsync, which has never produced 
really good results for me. In nvidia-settings I have turned on the sync 
to vblank option, without which I get tearing of image. If the OpenGL 
vsync playback option produced smoother playback for me, I guess I could 
use this instead.

For some problems I had related to jerky video after resuming from 
suspend-to-ram I turned off the support for AGP, i.e.:

Option      "NvAGP"     "0"

to the "Device" section for my "nvidia" card in my xorg.conf. I've also 
added:

Option      "RenderAccel"       "true"

I haven't done a rigorous test with and without this last setting, but I 
suspect it's pretty important. I've also commented out the dri module 
from the list, recommended by NVidia:

# Load  "dri"

Dunno if that does anything much, but I guess it's best to do what they 
recommend. The video mode is 1600x1200, as this the native resolution of 
the monitor I use for a TV.

I remember having a fiddle with the commercial flagging priority options 
in the backend too, which was mentioned earlier in this thread. I can't 
remember off the top of my head what I ended up setting here. Whatever 
the setting, I find it's pretty close to real-time, finishing not long 
after the recording ends (typically a matter of minutes).

Finally, I found using XFS as the filesystem for recordings made a 
_huge_ difference to performance. With this I went from a 
picture-in-picture mode where both video streams were effectively 
unwatchable, to just occasional lost frames in the smaller window. It's 
possible I changed something else at the same time, and it was some time 
ago, but I recall it seemed like XFS was an enormous improvement at the 
time. I don't know why this would be - perhaps it a lot more CPU friendly.

For a combined FE/BE system, with multiple HD tuners, lots of RAM is 
essential in my experience. Arch Linux provides a very stripped back 
basic install, so I'm only running just what I need for a dedicated 
mythbox, and I found I was getting out-of-memory errors with 512MB RAM + 
512MB swap. Also it was thrashing horribly. Installing 2GB RAM leaves a 
comfortable amount of headroom for my taste, although I could have got 
away with 1.5GB I guess. Whatever the situation for your config, I guess 
my point is that I think you'll be struggling to get decent playback 
performance if the system starts to swap.

That's pretty much all the details of the relevant config. Some of it's 
pretty specific to my particular setup. I hope it helps you get some 
good results too.

Cheers,
Leighton