$Id: pvrusb2-faq.html 643 2005-10-16 23:00:07Z isely $
Mike Isely <isely at pobox dot com>
The home location for this page is here.
This page describes list of common pitfalls (in no particular order) and their corresponding solutions when using the pvrusb2 linux driver. I have gathered up this list from e-mail correspondence over time, along with some lessons learned here. If there are things you think should be added here, please let me know.
You can find the main driver page on the web at http://www.isely.net/pvrusb2.html.
Feel free to e-mail me if you have any other questions.
Mike Isely <isely at pobox dot com>
Contents
1. When I try to install the driver with "make install" the installation fails.
2. Why am I not getting any sound?
3. Why can't I get this driver to work on an xbox?
4. The image is jumpy and the audio tends to lag.
5. I can't tune anything. I get either video snow or a blank screen.
6. I can't get xawtv to work.
7. I can't get mplayer to work.
8. I can't compile because tveeprom.h is missing or the compilation dies with a complaint about tvdata being an incomplete type.
9. I'm getting errors in the log about being unable to find pvrusb2.f1 or pvrusb2.f2.
10. I copied the driver module(s) into my system but the kernel is not loading them.
11. Sometimes streaming quits in xawtv.
12. Where the heck is /dev/input/eventX for my device?
13. Why did the device go batty when my air conditioning turned on?
14. Why must I be root to access the control files in sysfs?
15. I just added a second PVR USB2 and now the video is stuttering, corrupted and/or unstable.
16. Changing the balance, bass or treble doesn't have any effect.
17. Changing the audio mode (stereo / mono / sap) doesn't do anything!
18. Should I be worried if I see a message about a corrupt Hauppauge PROM?
That's because I screwed up when reworking the build process with the 20050527 snapshot. We're using Kbuild and the correct internal target is "modules_install" not "install". Previous snapshots should be OK because they predate the bug. Anything after 20050527 should be OK because it's been fixed. Note that in any case if you follow the procedure on the pvrusb2.html, then you're copying the modules by hand anyway, in which case this isn't an issue.
There are multiple possible causes for this problem. Check the following:
- Is msp3400.ko present and loaded? Try lsmod | grep msp3400. The pvrusb2 driver itself does not directly control the sound processor; instead that duty is offloaded to msp3400.ko which is included with video4linux (and the ivtv driver and for completeness there's a spare copy included with the driver snapshot). You need to ensure that msp3400.ko can be loaded. The driver will attempt to pull it in via modprobe when the driver itself is loaded, but any failure of that attempt will be silent (literally and figuratively). If it isn't there, then either rebuild your kernel with the module enabled within video4linux or ensure that you've installed the spare copy included with this snapshot.
- Did you just run xawtv and now you're trying to use mplayer (or probably anything else that pulls mpeg video)? In this case, xawtv mutes the audio on exit, and it will stay muted if the next application doesn't do anything to change the situation. This is in fact what will happen with mplayer if you run it in "dumb" mode. You can fix this by manually unmuting the sound using the sysfs interface. Turn off the "mute" control (and see the main pvrusb2 web page for information on how to use the sysfs interface).
- Is the driver's audio volume too low? Check that your app (e.g. xawtv) has the volume up.
- Check your mixer settings. Make sure your pcm channel is unmuted and the volume is high enough.
The problem is that the xbox has an I2C adapter controller in the xbox Linux software that is very hostile to the presence of other I2C busses showing up in the system. The pvrusb2 hardware has an internal I2C bus. The fix for this is to patch the xbox Linux software. Contact me for a patch.
Possibly your system isn't keeping up with the driver's bit rate. There are some things you can do to determine what is going on:
- Run top while running your app. How much CPU is left over? If you have less than about 20% CPU left (approx guess), then I'd suggest you need a faster system.
- Is the pvrusb2 device really connected to a USB2.0 controller and / or hub? Run usbview to inspect the device and see what rate it is going at. You may have problems if you are only running the device at USB 1.1 "hi-speed" rate.
- Try tweaking the video rendering settings of your app. For example, with mplayer, the "xv" output setting uses the XVideo extension and tries to do hardware video scaling - if your video card doesn't do hardware scaling very well, then the CPU could be getting taxed. Try the "x11" output setting and see if things improve. (In this case, top will likely reveal that you're gassing out the CPU.)
- Separate the video capture operation from the video rendering operation and see which side is taking all the CPU: Try just cat'ing /dev/video0 (or whatever the pvrusb2 device got assign) into a file. Then view that file in a separate step with mplayer. Look at the CPU utilization (e.g. use top) during both steps and see which part is taking all the CPU.
It is possible to have a very fast system but still have lousy video rendering performance. Good video rendering depends a lot on the video card you are using. For example I have found that Nvidia 5200-class video cards do hardware video scaling significantly better than ATI 9200-class video cards.
There are multiple possible causes for this problem. Check the following:
- Is tuner.ko present and loaded? Try lsmod | grep tuner. The pvrusb2 driver itself does not directly control the tuner; instead that duty is offloaded to tuner.ko which is included with video4linux (and the ivtv driver and for completeness there's a spare copy included with the driver snapshot). You need to ensure that tuner.ko can be loaded. The driver will attempt to pull it in via modprobe when the driver itself is loaded, but any failure of that attempt will be silent. If it isn't there, then either rebuild your kernel with the module enabled within video4linux or ensure that you've installed the spare copy included with this snapshot.
- You might have a Hauppauge "type 58" tuner in your pvrusb2. Some versions of tveeprom.ko floating around don't correctly map this to a type that tuner.ko can use - which then causes tuner.ko to give up trying to control your tuner. Do you see something like this in your system log?
tveeprom: tuner = Philips FM1236 MK3 (idx = 58, type = 4)If you do, then you have a type 58 tuner and it isn't being mapped properly (the mapped value "type = 4" part indicates a bad mapping. Definitely if you are using the tveeprom.ko that is part of your kernel tree then this may be a problem. Try using the tveeprom.ko module that is part of this driver snapshot. The main pvrusb2 web page has more information about this.
- You might have a tuner that is more recent than can be recognized by tveeprom.ko and / or tuner.ko. So far I know of no instances of this particular problem, but it can happen. This is a more general variant of the "type 58" problem above. Try to locate and use later versions of tuner.ko and tveeprom.ko - and please tell me if this happens.
There are multiple possible causes for this problem. Check the following:
- Any version of xawtv before 4.x has no chance - those earlier versions could not decode an mpeg2 stream. Update to something in 4.x if you are trying an older verison.
- You might not have compiled xawtv correctly. If the configuration step didn't find ffmpeg (I think) then it won't compile in any mpeg2 decoding logic and then you're no better off that a 3.x version. Similarly, it has to find and configure an mp3 decoder in order to correctly decode the audio.
- You might have a broken 4.x xawtv snapshot. Versions from early February 2005 are known to work (been using that as a test case). However there was a video streaming bug found & fixed around 20-May-2005 that would have prevented snapshots prior to that from working properly (and I guess since my Feb version worked, the bug must have been introduced into the code some time after that point).
Even though this driver is a video4linux driver, and mplayer is able to handle video4linux devices, you can't run mplayer against this driver in such a way that mplayer tries to treat it as a video4linux device. What happens when you try is that mplayer (1) can't grok v4l frames as mpeg2 data, and (2) even if it could, mplayer tries to use mmap() style I/O to fetch the video "frames" and that is not currently supported by the pvrusb2 driver.
The way to make mplayer work is just to not do anything special. Specify your video device name (e.g. /dev/video0) as the "file" to read - mplayer will then happily stream plain old mpeg2 data from the device. Yes, I know that means you can't use mplayer to adjust the device's controls, like for example changing the channel. However you can still use the driver's sysfs interface to do this while mplayer is running.
Another alternative solution you can try is the patched mplayer available with the ivtv driver. I haven't tried this, but I suspect the ivtv driver author patched mplayer to deal with exactly the problems I describe above. Thus if it works for ivtv it may very well also work for the pvrusb2 driver. (Please tell me if you try this and let me know if it worked.)
The tvdata structure is defined in tveeprom.h so the common solution is to find tveeprom.h. That header file is part of your kernel source tree. If it isn't there, then your kernel sources are too old to work with this driver. Update your kernel. Alternatively you can probably also work with a slightly older kernel that has been patched up with the latest video4linux snapshot. However I really recommend you go to a later kernel. A good choice known to work is 2.6.11.10.
Those two files are the firmware images that must be loaded into the pvrusb2 hardware before it will work properly. The firmware is not part of this snapshot, but you can extract it from your Windows drivers - which you should have gotten with the device. The extraction process is described here inside the utilities page.
You might have compiled for the wrong kernel version. The kernel loader will usually report this in a very unsubtle way in the system log.
If the kernel is complaining that it can't find the module, you might want to try this first:
depmod -aI leave it as an exercise to the reader to look up the man page for depmod to see why this is important :-)
This problem was mostly fixed as of the 20050626 snapshot of the driver. Are you using a recent enough snapshot?
The remaining issues right now I consider to be xawtv application issues. These problems include:
- Zero byte read requests - Sometimes xawtv will issue a read to the driver of size zero. Why? I have no idea. When this happens, the only thing the driver can do is return zero, but that is really an EOF, and xawtv responds by closing the stream. The driver will detect and report zero byte read requests to the system log. Look for messages of this form: "ZERO Request? Returning zero."
- If you are tuned to a weak station, video streaming can pause, due apparently to the pvrusb2 hardware struggling to acquire a lock on the video frames. If this pause is long enough (about 3 seconds) then xawtv will timeout with a "select timeout". There really isn't much the driver can do here when this happens. Instead xawtv should not give up reading.
Any time streaming quits in xawtv, you can always restart it by doing something that causes xawtv to stop then start again. Changing the channel for example is a way to kick the streaming going again.
There isn't any such device node entry for this driver. Aurelien's older driver directly integrated with the kernel's input system for IR processing; I removed all that logic in favor of allowing the lirc package to do the work of handling the IR processing. When you use lirc, input is captured differently, thus no /dev/input/eventX will be found for this driver. More info about this is described here on the main pvrusb2 page.
This is because your air conditioning compressor caused a temporary sag in your line power. While modern PC power supplies are pretty good at surviving such power abuse, your PVR USB2 device is externally powered using a cheap wall-wart which just can't defend against a power sag. So the result is a power glitch into the tuner's hardware and that can screw up video capture.
This sort of issue is not unique to the PVR USB2 device - it can happen for any device which has a separate external power supply (which would be typical of many USB devices). If this is a problem for you, get a UPS and plug your PVR USB2 device into it (along with the PC of course).
Files created in sysfs are initialized with a default user and group ids of root. There's no way to initialize them to anything else. Now, though the driver can't set the uid or gid, the driver can set the mode for each sysfs file it creates. So why not just make the files world writable? Because that would violate the security of the system. The simple fact is that there are things one can tweak here that would probably cause the driver to fail, which might be a way to destablize the system. (No, I don't know that for certain, but when you don't know, the correct action is really to not allow it in the first place.) Just accept the fact that for the same reason that permissions should be restricted for access, say your CD burner, that it should not be possible for just anyone to write information or otherwise control the pvrusb2 driver. That is why only root can access the control files in sysfs.
Now, with that said, there are other possibilities. While it should not be the business of the pvrusb2 driver to set fine grained security policy, there's no reason why one couldn't do other things in user space to solve the problem. Some possibilities include:
- Have a simple setuid wrapper program manipulate sysfs, based on sanitized commands given to it. The wrapper then effectively becomes the security cop.
- Modify the uid and gid of desired sysfs files from user space. You can chown / chgrp files directly. Perhaps you can set up designated "video" group whose members are permitted to touch the device.
- Program hotplug to adjust uids and/or gids for the driver's sysfs when it sees the device appear in the system. Such a script could implement a distribution-specific security policy, much like what is done for other devices (e.g. scanners). This is a refinement of the previous idea. If someone would like to contribute something to do this I can include it in the driver source tree.
Beyond instancing itself again, the driver doesn't have to do anything special to support multiple devices. So it should "just work".
However there can be hardware issues with such a configuration. The thing to watch out for is how you have your device(s) connected to the computer. If everything is using USB 2.0 running at hi-speed, then you should be fine (and if you are not contact me). A single PVR USB2 device plugged into a "full speed" USB 1.1 port will also work fine, but since "full speed" is at best 12mbps and your average mpeg2 stream is going to be around 6mbps or higher, then a second PVR USB2 device sharing that connection through a hub is going to cause trouble. There just isn't enough USB bandwidth in this case. If you are going to run multiple PVR USB2 devices, make sure that each has enough bandwidth available between it and the PC. Generally this means that if you are going to share a port using a hub, the hub at least must be a hi-speed hub and it must be connected to a hi-speed port.
Note that you can dump out the ctl_usb_speed control in sysfs for each device to find out what speed it thinks it is running at.
Handling of the various audio tone / balance settings is not directly implemented by the pvrusb2 driver. It just passes everything through to msp3400.ko for processing, and that module processes the settings into commands for the msp34xx chip inside the device. The problem here (at least for me and probably everyone) is that the particular msp34xx variant inside the PVR USB2 doesn't have the ability to adjust any of the balance, bass, or treble. The msp3400.ko tries to act like the capability is there, but it just doesn't work because it isn't implemented in the silicon. That's why it probably isn't working for you.
This of course leads to the obvious question: If it isn't going to work, then why do the controls exist in the driver? Answer: Because I'm not sure that it isn't going to work. It is conceivable that there might be some PVR USB2 variants floating around that happen to have the right kind of msp34xx part to implement this. Given Hauppauge's penchant for changing out parts without changing models, I'm not prepared to assume that the ability won't be there. So the driver makes these controls available and dutifully passes that information down to msp3400.ko which in turn tries to influence the (apparently) non-existent functionality. What would really be nice would be for msp3400.ko to provide a means to detect if balance / bass / treble are supported and to tell the parent driver this information. Then I could disable controls that obviously aren't going to work. But that ability as far as I can tell isn't there, and for now I'm going to assume that it might be there.
After a night of bug chasing, I believe I understand this problem, and it only affects those of us in NTSC territory.
Again, this is a case where the pvrusb2 driver just passes the information down to msp3400.ko and it's up to that module to act on the information to implement the correct mode. There's very little that the pvrusb2 driver can do to foul this up.
For all areas except NTSC there are 2 possible audio subchannels (I'm guessing this), and the msp34xx chip has the ability to select combinations of those two within a given mode. But with NTSC there are actually 3 possible audio subchannels that can be broadcast at the same time (stereo left, stereo right, sap), and the msp34xx chip has to handle this by pre-selecting a subset based on the mode setting. There are two NTSC "modes" because of this, so when switching between either stereo or sap one has to switch this mode in addition to switching the source. Unfortunately the implementation in msp3400.ko fails to do this. It just locks onto the first mode which selects the stereo choice. Given that many people using this module do not live in an NTSC area (I presume), this problem has probably gone unnoticed. I imagine that the ivtv driver likely has the same issue.
The fix for this needs to be in msp3400.ko, which I don't maintain. When switching to/from sap, the mode has to be manually switched to/from 0x0020 (BTSC stereo) and 0x0021 (BTSC sap). It might be possible to force this by disabling automatic mode selection in the mode and forcing video standard code 0x0021 on the module's option line, but I haven't tried this and it's really clunky to try to operate the tuner in this manner. If someone else would like to look into this, I would welcome the effort.
At some point in the future I may try to code a fix for this, but now isn't the time. There are two variants of this rather messy msp3400.ko module already floating around (kernel and ivtv) and I don't want to fork a 3rd version. The versions I'm looking at are already several months old. Before attacking something like this one would need to first go to bleeding edge versions and talk to the corresponding maintainers. I just don't have the time right now.
You might see a message in your system log that looks like this:
tveeprom 2-0050: Encountered bad packet header [c2]. Corrupt or not a Hauppauge eeprom.Yet even with such an alarming thing in the log, the PVR USB2 device operates correctly. This is because the tveeprom.ko module is trying on its own to parse the PROM data in the PVR USB2 and it frequently can't do that correctly without outside help. Later on the pvrusb2 driver will orchestrate that action, this time with the correct results, therefore this warning message can be ignored.
This message is coming from a support module, not the pvrusb2 driver itself, and so the pvrusb2 driver can't do much to control its appearance in the log. The interested reader may wish to read all about operation of tveeprom.ko, which is laid out in gory detail over in pvrusb2-eeprom.html.