[mythtv-users] My MythTV journey

[Brian Scully]

It has taken me about a month (@10-20 hours/wk) of work to get MythTV up and running.  You will notice that I made my life a little hard in the choices I made - so don't be put off by this number.  You also may decide that i'm an idiot after reading this post - so be it.  But hopefully I can share something useful with the readers of this list.  First my hardware:

Mobo: Abit NF7-S 2.0 ( NForce2 - first mistake )
CPU: Barton 2800+ w/ Coolermaster Fan
Memory: Crucial 512MB PC-2700
Vid Card: ASUS V9520 Video Suite:
 2x DVI out, TV-out, TV-in (non functional ... yet), Nvidia FX5200 chip ( second mistake )
DVD-ROM: Sony 16x DDU1621
Cap Card: Pinnacle PCTV/Studio
Sound: Onboard NF2 sound - VIA VT82C686B
Disk: Maxtor 4R160L0 160MB

Software:
Distribution: Debian testing/unstable current ( third mistake )
Kernel: 2.6.0-test11-bk5-bart1 + forcedeth patch + forcedeth-update-2 patch (fourth mistake)
Vid driver: NVIDIA binary 4620 + minion.de. patches
Sound: ALSA 1.0.0rc2
Vid Cap: BTTV 0.9.12 ( dist w/ kernel )

After building the hardware I installed Woody (don't try to install Sarge first - that is a bad idea - upgrade to Sarge).  It's sort of a chicken-egg problem getting networking to work, since the network driver doesn't ship with Woody, so another computer with a cd burner is VERY handy.  Once the network card was up and running, I started using apt to get up to date.  Of course this was my first time using Debian and I managed to foul things up pretty bad - I went a little crazy trying to upgrade to unstable, and had to back some packages out.  I upgraded ( accidentally ) to glibc-2.3.2 which introduces the Thread Local Storage code.  Well this managed to fubar X & the NVIDIA driver causing lockups & kernel oopses etc.  Oh and the minimum driver useful for an FX5200 is the 4496 ( I think this is a level beyond what is recommended for MythTV / NVIDIA ).

So instead of backing down to an older libc - I dl'ed a 2.6.0-test11 kernel kernel.org.  After some attempts at getting this configured correctly so it would boot, I finally got it up and running.  Well as you NForcers know, the kernel hard locks ( I was shocked to see linux do this ) after a short period of time.  Luckily I found the nforce2 APIC patch out on the LKML.  This is included in the test11-bk5-bart1 patch.  So everything was stable except the network was not working.  I found links to both forcedeth patches on the LKML - and downloaded them with an old, working kernel ( ALWAYS retain your old kernels ).  At that point the network worked, and myth could start up.  But every time it started, I got a message about not being able to write to /dev/dsp.  So I fixed the permissions.  Got the same message.  By the way - both mythfrontend & mythbackend do not like this happening.  They need a hard kill, and get zombied (catching SIGCHLD?) - in the case of the backend this can lock up the bttv driver so that it can't be unloaded, and a reboot is necessary - yuck.  

So I tried various audio drivers.  Of course since the chip is a VIA VT82xx, why not use the VT82xx drivers?  No.  The module loads fine, but /dev/dsp does not interact with the card (eg aplay /dev/dsp).  The intel 8x0 is the driver to use.  However - Debian unstable is alsa 0.9.14.  This doesn't support full-duplex (r/w) to the sound card in my testing.  Thus I had to upgrade to ALSA 1.0.0rc2 (latest).  I built this from scratch, and unloaded the apt packages.  After a reboot and some configuration issues, these drivers were up and running.  So now both the frontend and backend can access the sound card and mythtv is working...

... except the video and audio get choppy after recording for about 2-10 minutes.  I played with all the settings, extra audio buffering, jitter control - I even switched the recording codec to MPEG-4.  Nothing worked.

Looking at /var/log/messages - I can see LOTS of bttv messages about skipped frames due to IRQ latency.  I change the module options to gbuffers=32 (the max - also determined by some to not change a thing for anything except tvtime), chroma_agc=1. So I start moving my cap card around in the case from slot to slot.  That doesn't fix it either.  I did notice though that (by moving the card) I was able to get the vid card and cap card on separate IRQs.  I think this is important - check /proc/interrupts while the video is playing and look for shared interrupts (two modules on the same line).  I played in the BIOS and changed the number of clocks in the PCI setting ( increasing this increases bandwidth, and PCI latency ) from 32 -> 4.  No change.  Finally I disabled every onboard device except the ones I was using - no firewire, no usb, no SATA, ...  I also added a pci=noapic to the kernel boot line.  I think that APIC for NForce / linux just doesn't work well because ... voila - now it's working.

I've been watching LiveTV ever since then with only two (1 sec ish) skips for three hours.

Some recommendations based upon my experiences:
* Some people tell you that 256MB is enough.  top tells me that I am using all but 4-5MB of my 512MB of RAM.  I've got about 12MB in swap too.  Get plenty of RAM.  Hell, I may buy another stick - especially once I buy that second cap card.
* Be careful when upgrading through apt, stay away from TLS if at all possible
* ALSA should be built from scratch
* Stay away from nforce boards
* Run a 2.4 kernel
* Upgrade X as far as is reasonable
* Don't use twm or fvwm as your window manager (the whole window positioning thing is a pita) - I like fluxbox, it sticks the window somewhere on the screen w/o my intervention
* Try knoppmyth before debian if you're not well seasoned, or coming from RedHat/SuSE like me

Some requests of the developers:
* The unhappy paths for socket communications seem like they need a little attention - both the front and the back need to fail cleanly, cleanup zombies, and hopefully handle the exceptions.
* Why do I have to restart the backend so often?  It seems like everytime I change something in the frontend settings related to recording, playback or LiveTV (eg change the codec), I have to bounce the backend - the logs suggest something about the socket communications I think.
* Why is it that every time I start up the frontend, it tries to read the video from the Television (not Composite1) and NTSC?  The database (assuming i'm in the right spot) says composite 1 and NTSC.  v4lctl doesn't fix it.  The only thing that fixes it is running xawtv, changing to composite1/NTSC, and then starting mythfrontend.

If there's more information that the developers need to address these requests - let me know and i'll try and scrounge it up.  I'm a developer myself, but my C is rusty - so don't depend on me for patches.  I'm one of those lazy java developers ( woo-hoo built-in memory management ).  I'm not scared of Berkeley sockets though, so I may have a look...

If this helped anyone out - or wasn't enough information, let me know by replying to this post on myth-users.

Thanks for reading this far & Merry PVRing,
Brian

_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!