$Id: pvrusb2-faq.html 592 2005-09-11 22:54:49Z 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. If there are things you think should be added here, please let me know.
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?
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 in the source tree here.