Hauppauge PVR-500
Contents
Introduction
Hauppauge has been a leader in bringing TV functionality to the PC since 1992. The Company is the worldwide leading developer and manufacturer of analog and digital video cards.
The WinTV family consists of several models that include features such as FM Radio, IR remote control, digital video recording and digital TV reception. Although each model has distinct features, this family of products shares the same basic functionality: they all allow a PC user to have TV in a resizable window on their screen.
A.K.A.: pvr500
Capture Card Information | |
Vendors Website | http://hauppage.com/pages/products/data_pvr500mce.html |
Input Formats | not applicable |
Support Status | Both tuners are supported (behaves like two PVR-150's). VBI data is supported in newer versions of the IVTV driver. Works fine even on Athlon64. |
Driver | IvTV 0.4.0 or newer. ** 0.4.2 is required if you have Samsung tuners ** |
Sound Driver | not needed. The hardware MPEG encoder will multiplex the audio with the video stream. |
Chipset | Connexant cx2341x |
Hauppauge WinTV-PVR-500 MCE
- Dual 125 channel cable ready TV tuners, each with a dbx-TV stereo decoder
- Dual high quality MPEG2 video and audio encoders based on the Conexant -416 MPEG encoder
- One back panel composite/s-video plus stereo audio inputs to connect to cable or satellite set top boxes
- Two on-board A/V headers, to connect to two more A/V sources
- One A/V back panel set with S-Video, composite and left/right audio input connectors
- One FM radio receiver
Note: the WinTV-PVR-500 MCE does not come with a remote control or a software DVD decoder.
Installation
The IVTV project develops a kernel driver for Linux and a driver for X11 for hardware based on Conexant's CX23415/CX23416 codec chip such as the Hauppauge PVR 150/250/350/500 models. You need a 2.6.x kernel (2.6.14 or newer recommended) to make this work properly.
- Distribution specific guides
Troubleshoot Tips
Check the IVTV console output with dmesg
The output of the `dmesg` command should look like the following (used `egrep` to filter IVTV messages only)
dmesg | egrep -i '(ivtv|tveeprom|tuner)'
ivtv: ==================== START INIT IVTV ==================== ivtv: version 0.10.1 (tagged release) loading ivtv: Linux version: 2.6.18.7 preempt mod_unload K7 gcc-4.1 ivtv: In case of problems please include the debug info between ivtv: the START INIT IVTV and END INIT IVTV lines, along with ivtv: any module options, when mailing the ivtv-users mailinglist. ivtv0: Autodetected Hauppauge card (cx23416 based) ivtv0: loaded v4l-cx2341x-enc.fw firmware (376836 bytes) ivtv0: Encoder revision: 0x02060039 tveeprom 0-0050: Hauppauge model 23559, rev E696, serial# 9934323 tveeprom 0-0050: tuner model is Samsung TCPG 6121P30A (idx 96, type 73) tveeprom 0-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) (eeprom 0x74) tveeprom 0-0050: second tuner model is Philips TEA5768HL FM Radio (idx 101, type 62) tveeprom 0-0050: audio processor is CX25843 (idx 37) tveeprom 0-0050: decoder processor is CX25843 (idx 30) tveeprom 0-0050: has radio, has no IR remote ivtv0: Autodetected WinTV PVR 500 (unit #1) tuner 0-0043: chip found @ 0x86 (ivtv i2c driver #0) tda9887 0-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 0-0060: TEA5767 detected. tuner 0-0060: chip found @ 0xc0 (ivtv i2c driver #0) tuner 0-0060: type set to 62 (Philips TEA5767HN FM Radio) tuner 0-0061: chip found @ 0xc2 (ivtv i2c driver #0) cx25840 0-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0) wm8775 0-001b: chip found @ 0x36 (ivtv i2c driver #0) ivtv0: Registered device video0 for encoder MPEG (4 MB) ivtv0: Registered device video32 for encoder YUV (2 MB) ivtv0: Registered device vbi0 for encoder VBI (1 MB) ivtv0: Registered device video24 for encoder PCM audio (1 MB) ivtv0: Registered device radio0 for encoder radio tuner 0-0061: type set to 73 (Samsung TCPG 6121P30A) ivtv0: Initialized WinTV PVR 500 (unit #1), card #0 ivtv: ====================== NEXT CARD ====================== ivtv1: Autodetected Hauppauge card (cx23416 based) ivtv1: loaded v4l-cx2341x-enc.fw firmware (376836 bytes) ivtv1: Encoder revision: 0x02060039 tuner 1-0043: chip found @ 0x86 (ivtv i2c driver #1) tda9887 1-0043: tda988[5/6/7] found @ 0x43 (tuner) tuner 1-0061: chip found @ 0xc2 (ivtv i2c driver #1) cx25840 1-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #1) wm8775 1-001b: chip found @ 0x36 (ivtv i2c driver #1) tveeprom 1-0050: Hauppauge model 23559, rev E696, serial# 9934323 tveeprom 1-0050: tuner model is Samsung TCPG 6121P30A (idx 96, type 73) tveeprom 1-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/D1/K) (eeprom 0x74) tveeprom 1-0050: second tuner model is Philips TEA5768HL FM Radio (idx 101, type 62) tveeprom 1-0050: audio processor is CX25843 (idx 37) tveeprom 1-0050: decoder processor is CX25843 (idx 30) tveeprom 1-0050: has radio, has no IR remote ivtv1: Correcting tveeprom data: no radio present on second unit ivtv1: Autodetected WinTV PVR 500 (unit #2) ivtv1: Registered device video1 for encoder MPEG (4 MB) ivtv1: Registered device video33 for encoder YUV (2 MB) ivtv1: Registered device vbi1 for encoder VBI (1 MB) ivtv1: Registered device video25 for encoder PCM audio (1 MB) tuner 1-0061: type set to 73 (Samsung TCPG 6121P30A) ivtv1: Initialized WinTV PVR 500 (unit #2), card #1 ivtv: ==================== END INIT IVTV ====================
check your ivtv version
To check what version is installed, issue the command:
rpm -qa | grep ivtv
Your output should look something like:
ivtv-kmp-default-0.10.3 ivtv-0.10.3
Check on http://ivtvdriver.org if you have the correct version for your kernel/hardware.
check video devices
8.) Check if the video devices are available to the system:
ls /dev/vi* -l
Your output should look something like this example:
lrwxrwxrwx 1 root root 6 Dec 29 06:27 /dev/video -> video0 crw-rw----+ 1 root video 81, 0 Dec 29 06:27 /dev/video0 crw-rw----+ 1 root video 81, 1 Dec 29 06:27 /dev/video1 crw-rw----+ 1 root video 81, 24 Dec 29 06:27 /dev/video24 crw-rw----+ 1 root video 81, 25 Dec 29 06:27 /dev/video25 crw-rw----+ 1 root video 81, 32 Dec 29 06:27 /dev/video32 crw-rw----+ 1 root video 81, 33 Dec 29 06:27 /dev/video33
Here is what each device corresponds to in this case:
Tuner unit #1: - For your info
/dev/video0 – The encoding capture device (Read-only) /dev/video24 – The raw audio capture device (Read-only) /dev/video32 – The raw video capture device (Read-only) /dev/radio – The radio tuner device /dev/vbi0 – The "vertical blank interval" (Teletext) capture device
Tuner unit #2: - For your info
/dev/video1 – The encoding capture device (Read-only) /dev/video25 – The raw audio capture device (Read-only) /dev/video33 – The raw video capture device (Read-only) /dev/vbi1 – The "vertical blank interval" (Teletext) capture device
Issues and Problems
Note: If you have other Video4Linux driver modules present (such as components of the bttv driver) the modules to drive the tuners may conflict with the ivtv modules and prevent the card's tuners from being properly detected.
Kernel Recommendations
You need a 2.6.x kernel (2.6.14 or newer recommended) to make this work properly. The drivers work with the 2.4 kernel, but only with certain patches. One has been made for 0.4.1 on 2.4.20 and is an open ticket in the IVTV trac system. You will have the best results with the 2.6.x kernel series. If at all possible, you should attempt to use kernel 2.6.17.x and ivtv 0.7.0 as this will result in the least problems of all.
Pre-emptive Multitasking Warning (common to IVTV)
Warning: Do not attempt to enable pre-emptive kernel locks in your kernel configuration--the ivtv modules do not get along with them and will cause spontaneous reboots.
Signal Strength Warning
Your cable feed usually only has enough drive power for 2 or 3 TV sets. If you're driving a large number of devices, you may need an RF Amplifier to boost signal strength. Conversely, your house cable may be supplying too much power to the PVR 500. Ivtv developers have noted that the Samsung tuners used in later PVR 500s are rather sensitive and will show a grainy picture if supplied with too high a signal level. In this case you must reduce signal strength by either inserting a 'pad' (a resistor) between the PVR and the cable, or if your house has a cable amplifier, by reducing the gain on the amplifier.
Outdated Repository
Additionally, installing current firmware and PVR150/500 specific audio firmware from the atrpms repo using Jarod's:
yum install ivtv-firmware yum install ivtv-firmware-audio
does not provide you with the latest and greatest recommended firmware as the folks at ivtvdriver.org suggest.
While most of the people will ignore the ivtv warnings displayed by using:
/bin/dmesg | grep ivtv
related to buggy firmware... it becomes a big problem when you use the PVR500 in conjunction with the PVR350. (Presumably this happens with the use of PVR150 and PVR250s too, but I can't confirm that.)
Symptons include loss of audio on both the PVR500 tuners and inability to change channels. The PVR350(s) will work fine though. Follow the ivtvdriver.org people's advice and download, extract, and install the recommended firmware.
Motherboard Incompatibility
Those of you with the ASUS A8V board will be disappointed to know that there appears to be no way to get this board to work with a PVR-500 if you are using the AGP port. The PVR-500 has its own PCI bridge and the AGP port on the motherboard is also on a PCI bridge, and the second PCI bridge fatally confuses the BIOS when it goes to initialize the hardware for booting after the system inventory screen. The recommended (and only known) workaround is simply to replace your AGP video card with a PCI video card. One might also trade in the PVR-500 for a pair of PVR-150's, but since the PVR-500 costs more than a new motherboard that doesn't make much financial sense (cheaper to buy a different mainboard). Some other ASUS A8V-xx models are also affected by this bug, but can be made to work with a BIOS update. For other uses the ASUS A8V is a fairly nice board, and the PVR-500 is a fairly nice card, the board is just flawed in a way that makes it impossible to use anything with its own PCI bridge.
Audio Instability
There appear to be well-known and repeatable audio quality problems (everywhere you google) about Hauppauge PVR-xxx cards and MythTv. From weeks of Googling for help and testing combinations of IVTV drivers, Myth versions, kernel versions, hardware settings etc., I've come to the conclusion that Myth does not cleanly set (and reset) the audio channel on channel change, or system startup. ivtvctrl -q0 -d0, ivtvctrl -q0 -d1 repeated a couple of times temporarily corrects the audio problems (until next channel change). The problems may be timing-related in the API between MythTv and IVTV. I will be looking into the source to investigate the API issues between IVTV and MythTv. I'll post results. Currently running MythTV 0.20, ivtv 0.4.7, kernel (Ubuntu Dapper) 2.6.15-27-amd64-generic, PVR-500, Nvidia GeForce etc. No dmesg problems reported, no logged mythtv problems, no logged ivtv problems (ivtvctrl -D 99). To the software things look okay - to the listener, audio is clobbered.
Unreasonably low latency
The following files in /var/log may contain a message "Unreasonably low latency" from ivtv:
/var/log/debug /var/log/dmesg /var/log/kern.log /var/log/messages /var/log/syslog
If you find such messages you should probably read the page on PCI Latency
FAQs
No sound on first recording
I had the problem that the first time mythtv tunes to a channel (live-tv and recording) sound is not working. Changing channels fixed the sound. I had this problem with ivtv 0.4.1 and 0.4.2. After some help from the mailing list, I found out that executing
ivtvctl -d /dev/video0 -q 0
fixes the sound. I don't know what this command does. However, I had to manually issue this each time I tuned the first time with a tuner. If I execute ivtvctl a second time, I get a sound hickup. So only execute this command once if a tuner is recording. To ease my life, I created this script:
#!/bin/sh # Some variables used to remember if the device is in use or not record_video0=NO record_video1=NO # Loop forever while true do # Is the video device in use ? fuser /dev/video0 2>/dev/null >/dev/null if [ $? -eq 0 ] then # Something is using video device and this is the first time we notice this if [[ "$record_video0" = "NO" ]] then date echo " recording on video0" ivtvctl -d /dev/video0 -q 0 echo fi record_video0=YES else # Not recording if [[ "$record_video0" = "YES" ]] then date echo " not recording anymore on video0" echo fi record_video0=NO fi # Do the same for the other device ....... fuser /dev/video1 2>/dev/null >/dev/null if [ $? -eq 0 ] then if [[ "$record_video1" = "NO" ]] then date echo " recording on video1" ivtvctl -d /dev/video1 -q 0 echo fi record_video1=YES else if [[ "$record_video1" = "YES" ]] then date echo " not recording anymore on video1" echo fi record_video1=NO fi sleep 1 done
User Experiences
If you have this card, speak up! This is a good place to note your experiences - ease of install, what you like, what's not to like, etc.
I have not actually got this card working on my myth box (it arrives tomorrow), but this link indicates it can be done.
http://www.bitbenderforums.com/~ralpha6/knoppmyth/knoppmythtv.htm
- JB notes: I've had this card up and running for almost 2 months now. It works well, but I feel the quality on the pvr250 was better (input welcome here...)
A fairly recent knoppmyth and an ivtv update were all I needed to get it working. I'm using the built-in tuner as one input, and s-video as the second. I'm not thrilled with the channel mappings yet (but too lazy to fix them...)
- Kris Rose: I am running the PVR-500 for several weeks now. I also found that it is slightly lower quality (more "grainy" and with scratchy sound on the S-Video) than my previous PVR-350 was but making sure the coax cable was grounded improved the quality somewhat.
- KK notes: I have this card in a backend system on knoppmyth30.1 and works flawless and the quality is that of analog cable it works flawless (MSI845U motherboard 512ram)
- JL notes: I am using Knoppmyth 5A30 and I haven't gotten it to work. The pvr-250 I have in my machine works, but not the 500.
- GA notes: If you have the newer version of the card with the Samsung tuners, you'll need at the very least ivtv 0.4.2, and patch tuner.c to version 3150 to fix the tuning.
http://ivtvdriver.org/viewcvs/ivtv/branches/0.4/driver/tuner.c?rev=3150&r1=3120&r2=3150
- FLOW notes: I have this running myth .19 under PLUTO .38 - works ok , a bit grainy as mentioned above and I cannot get PIP to work!
- Claus Andersen notes: I have this running myth .19 - PIP works but only when XvMC is disabled (see XvMC Caveats)
Colours looking OK first time I select LiveTV. Exit to main menu and re-enter LiveTV and the colours are faded/washed out (everything looks blueish). Reboot fixes problem. I upgraded to .20 and have not seen this problem again! Everything "just-works" and is smooth (even OSD) on a VIA EPIA SP8000 (800Mhz C3).
- JS notes: I have been running this card for six months now in a gentoo based myth system. The results have been very mixed along the way. This card is wonderful, when everything is workign together properly, but it is also very tempermental. With earlier versions of ivtv I found I was unable to use video0. Despite the annoyance of getting it workign properly, I highly recomend this card for myth setups.
- JJ notes: I had issues with my PVR-500 that is running alongside a PVR-250 using IVTV version 0.4.3. The first tuner on the card had no audio. No combination of ivtvctl -d /dev/videoX -q X would provide audio. Upon examining the boot logs, I discovered when the audio wasn't working when that particular tuner was being initialized the log reported:
cx25840 2-0044: unable to open firmware v4l-cx25840.fw
but when the audio is working it reports:
cx25840 2-0044: loaded v4l-cx25840.fw firmware (14264 bytes)
It seems to be some sort of timing issue (the hotplug driver isn't loading the firmware fast enough?), it always happens on the first tuner of the card. The second tuner always loads the firmware correctly. The "power off for 30 seconds" recommendation from the IVTV site seems to fix the problem (at least for that boot) but I sure would like a more robust solution.
- LL Notes: 1 PVR-500, Slackware 10.2, MythTV .19, ivtv .0.4.3 This card is working well, fortunately I have not run into any technical issues. Picture Quality is a little lack luster.
- TiTaN_pi8 Notes: I have a MythTV box running Debian, MythTV 0.19 CVS with IVTV 0.6.3. Everything works well, even teletext (closed captioning), unfortunately, like many others, the picture quality is not that great (colors/saturation bad and some scan lines) but enough to watch it from a distance (like you should! ;).
- CM Notes: I have a PVR500, Mythtv 0.20. This card is working great. I have a remote that came with the card which I can't get to work. It has a usb receiver with. I have LIRC .8 on it.
- KCarmich Notes: I have a new PVR500 that uses the Samsung Tuner, this did cause problems for me until I updated the kernel to 2.6.18. The video quality was horrible with most channels with so much static that it was not watchable. If you are going to use this card you should have the tuner.c patch or be running 2.6.18 or later, with ivtv 0.8+, the video quality is not as good as the PVR150 in the same box, I would recommend that you use 2 PVR150's if you can handle using the additional PCI slot.
- Briand Notes: I have a PVR-350 and a PVR-500 (with Phillips tuners), and have had both cards running in harmony since 0.19 in my Asus Pundit-R using ivtv 0.4.0 (tagged release). I recently rebuilt a new mythtv box, using an Asus P4V8X-MX motherboard and using the AGP slot on it for my NVidia FX5200, under MythTV 0.20 SVN using ivtv 0.8.0 (FC5 2.6.18). The machine originally would not boot past POST with the BIOS as shipped when either/both Hauppauge cards were installed. Upgraded the BIOS to latest revision, and have had no problems since.
- Calvin Dodge Notes: I have a PVR-500 which was getting really bad signal quality on some channels (on other channels this would occur only when the show credits were being displayed). For other reasons I happened to change the default horizontal capture resolution from 480 to 720, and the signal quality problem disappeared.
- lowone notes: I was having same issue as Calvin Dodge above did. It is the correct fix and makes it so beautiful. This is an ivtv driver issue and here is the link to gossamer about it: http://www.gossamer-threads.com/lists/ivtv/devel/33735
- rubicante notes: I got a PVR-500 in November with Samsung tuners and it sucks. The higher channels were snowy and the lower channels I could barely make out. The pvr500_samsung_patch_2.6.17.diff patch helped but did not fix the problem; It just made all channels consistently snowy. Even after re-installing the card on a seperate Windows box with SageTV I still get snowy channels. Thread below has more info. (12/13/06)
http://forums.snapstream.com/vb/showthread.php?t=33675
- Michel notes: On my Debian GNU/Linux 4.0 system I used the IVTV drivers version 0.8.2, which were shipped with this distribution. My card has samsung tuners, and the combination of these 0.8.2 drivers in combination with the 2.6.18.7 kernel was just... plug-and-play :-)
However, sometimes my system became unstable, so I grabbed the 0.10.1 drivers from the 'sid' distribution.
Signal quality is same to the PVR150 that was previously in my system; Please note I reworked the entire cabling system in my house using a steel splitter, which is definitely the reason why this setup provides such good quality video signal. If someone is interested in how to rewire the cabling system, let me know. Maybe I should write a wiki page about that subject?
- AntiNorm notes: Works flawlessly under MythDora 3.2, and was easy to install.