[Edgy PATCH] Radio on PVR-150 outputs only noise.

Here is the patch from the e-mail thread, redone for linux 2.6.17. It corrects the values sent to the PVR-150 with TAPE-H001F tuner so that the radio works correctly instead of outputting only noise.

I can confirm the bug in question -- at least on the PVR-350 card. It utilizes the same tuner (from dmesg):

tveeprom 0-0050: tuner model is LG TAPE H001F MK3 (idx 68, type 47)

If it would be helpful, I would be willing to apply the patch and recompile the kernel to test this patch with a PVR-350. (While I have rolled kernels before, I have not done so with patches, so I may need the teensiest bit of assistance, but I promise to not be obnoxious.) Please email me or reply to this thread if you'd like me to give it a shot.

It would be nice to have someone else confirm this. This is how I built my kernel. I'm almost certain there are easier ways, but this is how I did it.

% apt-get source linux-source-2.6.17
% cd linux-source-2.6.17-2.6.17.1/
% cat /path/to/pvr-150-radio-output.patch | patch -p1 --dry-run
% cat /path/to/pvr-150-radio-output.patch | patch -p1
% fakeroot dpkg-buildpackage -b -nc
.... wait, wait, wait, wait, wait!!!! ....
.... eventually end up with a linux-image-2.6.17-10-386_2.6.17.1-10.34_i386.deb package that has the patch applied....

You can install that package, but rather than do all that just to replace one file, I found the compiled module file at

..../linux-source-2.6.17-2.6.17.1/debian/build/build-386/drivers/media/video/tuner.ko

in the source/build directory and replaced the non-working tuner.ko (located at /lib/modules/2.6.17-10-386/kernel/drivers/media/video/tuner.ko) with the patched version of tuner.ko. Unload the ivtv and tuner modules, then reload the ivtv module. The first time I just tried loading the tuner module, but the tuner type didn't get set correctly. Having the ivtv module load the tuner made it set the tuner correctly. After patching and replacing tuner.ko, I am able to use the ivtv-radio program from the ivtv source (compiled when the ivtv.ko module was compiled) to tune radio stations by executing "ivtv-radio -f {frequency}".

Hope that description helps. And, if someone has an easier way to compile the kernel with all the same patches and configuration that the original kernel has, please let me know.

Confirming the patch works for PVR-350 as well.

Here's my How-To:

I grabbed the latest 2.6.17-10-generic source, copied to a new directory so I could screw things up, went to that directory and did the following:

make oldconfig
make

and waited a long time before I could grab the module from [path-to-source-tree]/drivers/media/video/tuner.ko

modprobe -r ivtv
modprobe -r tuner
modprobe ivtv (will auto-load tuner as a dependency)

And lo and behold, the damned radio works!

My understanding is that this issue will be patched in kernel 2.6.20 -- if that goes out before the KernelFreeze deadline, no distro-specific work would have to be done to fix this in Upstream.

This might be worth throwing together a Wiki page... I don't have time right now, but could do that at some point in the rather indefinite future.

There's already a short wiki page about it on the ivtvdriver.org site. See

http://www.ivtvdriver.org/index.php/Howto:Radio_tuner

It looks like it could be expanded a bit, though.

Hm. It seems with the new tuner.ko, I have a flickering of the top sixth or so of the frame in video playback mode.

However, when I unload that and go back to the old tuner.ko, the video problems are resolved. I take it the new tuner file causes no problems for your setup?

No, I do not see any problems like that. Of course, I have the PVR-150 which doesn't include hardware playback, so all my playback is software only. That sounds like a question for the upstream ivtv driver developers.

Hi,

This bug was opened a while ago but there hasn't been any recent activity. Just curious if this is still an issue with the latest Hardy Heron 8.04 Alpha release which is currently under development and contains an updated version of the kernel. It would be helpful if you could test the latest Hardy Alpha release: http://www.ubuntu.com/testing . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. We'll keep this report open against the actively developed kernel but against 2.6.17 this will be closed. Thanks.

It doesn't speak well to a project when a user

1. Finds a bug
2. Find a fix for the bug
3. Creates a patch for the bug
4. Files a bug with project and uploads the patch

And then after all that work, the bug is completely ignored for over a year before it's finally marked "won't fix". To me, that doesn't seem to be a good way to promote involvement in a project. I'm not very inclined to put forth this effort again when last time I was pretty much ignored, except by another user who had the same problem.

That said, according to http://www.video4linux.org/changeset/4927%3A09e46aea3bc7 this patch made it into V4L over a year ago and current versions of Ubuntu use kernels that include this patch. I have not yet installed Hardy but I did verify that it was in the 2.6.22 source from the current Mythbuntu. So, since you're not planning on fixing the older version, this bug can be closed.

I don't really think that's a fair criticism, Tanner, given that the original bug post notes that there was an extant upstream patch -- an upstream version that the Ubuntu roadmap had already committed to merging in a future release, thus making a fix in the current release a backport at best.

What complicates the situation further is that the Canonical patching policy is pretty clear that post-release patches will be security-only, as the feature freeze for Edgy had passed when this bug was filed. While it was clearly an important issue at the time, and I appreciate your work in filing this bug to fix the then-current version of Ubuntu, this patch was not security-related, so the expectation of having that bug handled for feature-addition in the same release was unreasonable.

"won't fix" is fine and expected for this bug in Edgy; "upstream fix" is appropriate for future releases. Thanks to the triage team for making their way around here, but what luck, that the upstream codebase has already fixed this issue!

Hi Chuck,

Actually, it's not true that post-release patches must be "security-only". According to https://wiki.ubuntu.com/KernelUpdates they are also appropriate for "Critical bug fixes" and "Supported vendor patches". Since they define "Critical bug fixes" as "non-security issues relating to bugs that affect a large range of users" this would not fall under that classification (since it only affects those with this particular hardware). This would then fall under "Supported vendor patches". In hindsight, I should have probably compiled my own package and put it in a "separate repository/pocket/PPA".

That wasn't my main criticism, however. My main criticism was that the bug was _completely_ ignored for well over a year and 2 versions past what it applied to. Even a simple comment on this bug that mentioned the kernel update policy or even just a modification of the "Importance" field would have been enough for me to withdraw that criticism. However, the way it appears to me is that Ubuntu can't even keep up with the bugs that its users submit so why should they bother. I hate to see Ubuntu fail under the weight of its own popularity but I suppose that's simply the price of "success".

BTW, I do want to thank you for your comments and investigations of this when I first submitted it. I thought they were very helpful!

Ha, touche. My mistake; thanks for the link. Point taken ;)