[pvrusb2] Problems getting PVR USB2 working on debian etch

Tue Sep 4 15:40:04 CDT 2007

Mike Isely wrote:
> On Tue, 4 Sep 2007, Eric A. Bonney wrote:
>
>   
>> Mike Isely wrote:
>>     
>>> On Tue, 4 Sep 2007, Eric A. Bonney wrote:
>>>
>>>   
>>>       
>>>> I am running kernal 2.6.18-5, debian etch. I have installed the firmware 
>>>> and followed the items on the website but I am still not able to get my 
>>>> device working. I know it is being seen by the system as I see it in the 
>>>> logs. I was wondering if there is anything I need to do in order to get 
>>>> this working on my system? Do I need to recompile the kernel to get the 
>>>> driver support or is it there already?
>>>>
>>>>     
>>>>         
>>> Eric:
>>>
>>> I need more information to diagnose this.  A copy of the part of your 
>>> dmesg output where the device is being seen would be very helpful.  We 
>>> need to determine at what stage things are going wrong for you.
>>>
>>>   -Mike
>>>
>>>   
>>>       
>> Mike:
>>
>> Ok so here is what is the information that I think you need from my 
>> dmesg output.  Please let me know if you need something else.
>>
>> Linux video capture interface: v2.00
>> usbcore: registered new driver pvrusb2
>> drivers/media/video/pvrusb2/pvrusb2-main.c: Hauppauge WinTV-PVR-USB2 
>> MPEG2 Encoder/Tuner : V4L in-tree version
>> drivers/media/video/pvrusb2/pvrusb2-main.c: Debug mask is 15 (0xf)
>> pvrusb2: Device microcontroller firmware (re)loaded; it should now reset 
>> and reconnect.
>> usb 1-1: USB disconnect, address 8
>> usb 1-1: new full speed USB device using ohci_hcd and address 9
>> usb 1-1: configuration #1 chosen from 1 choice
>> usb 1-1: reset full speed USB device using ohci_hcd and address 9
>> cx25840 0-0044: cx25843-23 found @ 0x88 (pvrusb2_a)
>> cx25840 0-0044: loaded v4l-cx25840.fw firmware (12559 bytes)
>> tuner 0-0043: chip found @ 0x86 (pvrusb2_a)
>> tda9887 0-0043: tda988[5/6/7] found @ 0x43 (tuner)
>> tuner 0-0061: chip found @ 0xc2 (pvrusb2_a)
>> wm8775 0-001b: chip found @ 0x36 (pvrusb2_a)
>> tveeprom 0-00a2: Hauppauge model 24012, rev E1A3, serial# 10130578
>> tveeprom 0-00a2: tuner model is TCL MFNM05-4 (idx 103, type 43)
>> tveeprom 0-00a2: TV standards NTSC(M) (eeprom 0x08)
>> tveeprom 0-00a2: audio processor is CX25843 (idx 37)
>> tveeprom 0-00a2: decoder processor is CX25843 (idx 30)
>> tveeprom 0-00a2: has radio, has IR remote
>> tuner 0-0061: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F))
>> cx25840 0-0044: Video signal:              not present
>> cx25840 0-0044: Detected format:           NTSC-M
>> cx25840 0-0044: Specified standard:        PAL-M
>> cx25840 0-0044: Specified video input:     Composite 7
>> cx25840 0-0044: Specified audioclock freq: 44100 Hz
>> cx25840 0-0044: Detected audio mode:       forced mode
>> cx25840 0-0044: Detected audio standard:   no detected audio standard
>> cx25840 0-0044: Audio muted:               yes
>> cx25840 0-0044: Audio microcontroller:     running
>> cx25840 0-0044: Configured audio standard: automatic detection
>> cx25840 0-0044: Configured audio system:   BTSC
>> cx25840 0-0044: Specified audio input:     Tuner (In8)
>> cx25840 0-0044: Preferred audio mode:      stereo
>> tda9887 0-0043: Data bytes: b=0x14 c=0x30 e=0x44
>> tuner 0-0061: Tuner mode:      analog TV
>> tuner 0-0061: Frequency:       175.25 MHz
>> tuner 0-0061: Standard:        0x00000100
>> wm8775 0-001b: Input: 2
>> pvrusb2: Device initialization completed successfully.
>> pvrusb2: registered device video0 [mpeg]
>>
>> Thanks,
>> -Eric
>>     
>
> OK, a lot of right things have happened here.  You're running the in-V4L 
> or in-kernel driver (more likely the in-kernel driver).  All the 
> firmware files have been found and loaded successfully, the various 
> chip-level drivers have all attached and are doing their thing, and the 
> pvrusb2 driver itself completed its initialization successfully and has 
> registered itself with the V4L core.  Assuming that you are using udev 
> (this is more the rule than the exception these days), then you should 
> see a /dev/video0 device node present in your system.  You should also 
> see a /sys/class/pvrusb2 hierarchy now with a sn-xxxxxx subdirectory 
> ("xxxxxx" will be your device's serial number).  If you have that 
> /sys/class/pvrusb2/sn-xxxxxx directory present then there's lots of 
> things that can be done to poke at the device.  Can you confirm that 
> these things are present?  If they are, then you should be able to try 
> mplayer or vlc or xawtv (or for that matter mythtv) with it.  See the 
> pvrusb2 usage documentation here for more information.
>
> One problem I do see however is that the wrong video standard is being 
> selected.  I already know what's wrong here, and I have a fix coming for 
> this.  It's not a fatal problem.  The interaction between tveeprom (a 
> module that reads out the device's ROM-resident configuration data) and 
> the pvrusb2 driver is causing it to select PAL-M as the default 
> standard.  I'm betting that it should be NTSC-M for you.  This issue is 
> currently only a problem for the in-V4L and in-kernel versions of the 
> driver; the standalone driver is wired to prefer NTSC over PAL if both 
> are available so it doesn't happen there (and the latest standalone 
> snapshot from last week also has a specific fix).  There are multiple 
> ways to deal with this.  Probably the quickest is just to use the sysfs 
> interface to immediately change the standard to NTSC-M.  This command 
> will do the trick:
>
> 	echo "NTSC-M" >/sys/class/pvrusb2/sn-*/ctl_video_standard/cur_val
>
> Another (more persistent) solution is to specify the standard as a 
> module option when the pvrusb2 driver is loaded; check the pvrusb2 usage 
> documentation for more information on this.  And another solution 
> (though this qualifies as an elephant-gun approach) is to build and 
> install the standalone driver.  A pure V4L app should also be able to 
> tell the driver what standard it should use; xawtv IIRC should be able 
> to do this.
>
> However I'm not sure if you've actually gotten far enough to hit that 
> problem.  My experience with accidentally running PAL-M in NTSC-M 
> territory is that if it is wrong you'll get a signal but the video will 
> be B&W with what looks like interference patterns overlaid.  You said it 
> just "isn't working"; that sounds more serious so maybe you're having a 
> different problem.
>
> BTW, this PAL-M vs NTSC-M problem also does not happen at all for 29xxx 
> devices - in that case the standard is still set wrong however the 
> saa7115 video digitizer in that device (the 24xxx devices use a cx25843) 
> seems to instead be autodetecting and using the right video standard in 
> spite of being told the wrong one.
>
>   -Mike
>
>
>
>   
Mike:

Thanks for the help...I am not sure what happened, bu this time when I 
went in and looked I did in fact have the /dev/video0 and the 
/sys/class/pvrusb2/snxxxxxx directories. I am not moving on to testing 
to make sure everything is working and hopefully I'll be ready to rock 
and roll later this evening. :)  I truly appreciate all the help you 
folks give to this community, even to newbies such as myself.

-Eric