So I bought the “PVR-250”:http://www.hauppauge.com/html/wintvpvr250_datasheet.htm (on sale at “Best Buy”:http://www.bestbuy.ca/” :-), and slapped it into my P933 to play. The install was easy, and the hardware looks nicely designed. But the software that comes with the card sucks. I don’t know how hardware guys manage so consistently to ship their products with truly crappy software. Simple stuff like you can’t tab between fields, if you set a record time before you change the date the time quietly resets itself (because you can’t record in the past, I guess), and so on. It’s very _pretty_ though; if they had put all that skinning effort into usability…
Anyway, that’s not important, since I also downloaded “KnoppMyth”:http://www.mysettopbox.tv/knoppmyth.html in order to try out “MythTV”:http://www.mythtv.org/. I picked KnoppMyth figuring that I could find out if it worked and I liked the system, and then I could build from scratch if necessary later on. I’m glad I did; building a MythTV system from scratch is not for the faint of heart (and this from me, who likes tinkering with Linux :-).
First problem was getting the “TV-Out on my Matrox G400 to work properly”:http://www.gossamer-threads.com/lists/mythtv/dev/2993#2993. After several tries with various different X drivers and configurations, I finally discovered the real problem: the KnoppMyth kernel comes with the vesafb framebuffer driver compiled in, so my Matrox G400 modules were never getting loaded. One kernel rebuild (and several hours) later, I had TV out.
The next problem was the network. My on-the-motherboard, Intel-based network interface (from the 82801 chipset?) kept “freezing”, with a timeout: “eth0: wait_for_cmd_done timeout!”. Lots of googling revealed that this is a known problem that apparently still hasn’t been fixed. Fortunately, There is an “Intel provided e100 driver”:http://downloadfinder.intel.com/scripts-df/Detail_Desc.asp?ProductID=61&DwnldID=2896 that supports this chipset, and _that_ one works. Download, build the module, and install.
Next was sound. After every reboot, the audio out would be muted, and I would have to login remotely and use alsamixer to manually unmute the Headphone audio out and then pump the volume up. Again, it turns out that this a known problem, and that the usual fix (alsactl save/alsactl restore) doesn’t work, because the ALSA software doesn’t save information about the Headphone output? Strange, but one again I found a workaround. Running
/usr/bin/amixer sset Headphone unmute 100
would unmute the Headphone output and set the volume to max; I stuck this in /etc/init.d/local so that it would run on every reboot.
Finally, the machine kept crashing with out-of-memory errors. I never did figure this one out, because I made two changes at the same time. I downloaded and installed the “latest ivtv drivers”:http://67.18.1.101/~ckennedy/ivtv/, and I also discovered that the MythTV cache file I had configured was larger than the cache filesystem (this would cause mmap() based access to fail with the aforementioned out of memory errors :-). I’m not sure which fixed the problem, but the box has been up and recording for a week now with no problems.
Now to figure out all of this transcoding stuff…
(Oh ya, and Richard Dean Anderson was very young when MacGyver was produced :-)
How does the quality of the recordings rate? Especially in comparison with (a) (S-)VHS tape, and (b) BitTorrent downloads. I would expect it to be about halfway between.
Of course, if you get one of those HDTV video capture cards, then you would get better than BitTorrent, since they are all only 640 pixels wide. :-)
I used to tape at LP on my VCR, so the image quality is quite a bit better. TV quality is worse than the XviD’s I’ve downloaded, but they usually start from digital satellite HDTV, as compared to my crappy analog cable signal.
The convenience is much more of an issue than the quality, for me. Besides, it’s NTSC; how much _worse_ can it get? (grin)