[pvrusb2] Problems getting PVR USB2 working on debian etch

[Mike Isely]

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 Isely          |     PGP fingerprint
     Spammers Die!!     |                             | 03 54 43 4D 75 E5 CC 92
                        |   isely @ pobox (dot) com   | 71 16 01 E2 B5 F5 C1 E8
                        |                             |