[mythtv-users] HD-PVR Issues

Alan Young ayoung at teleport.com
Fri Mar 5 21:48:52 UTC 2010


On 03/04/2010 07:02 PM, Jeff Wormsley wrote:
> Alan Young wrote:
>> You should be able to change them with the v4l2-ctl command. And as
>> root, I think you can change them by echoing the value into the file.
>> To set the defaults when the driver loads, they are set through module
>> parms. Where the parms are specified I think it might depend on the
>> distribution. For Fedora, I have a file in /etc/modprobe.d. I call it
>> hdpvr.conf and it looks like:
>>
>> options hdpvr default_audio_input=2 default_video_input=0
>>
>> After you make that change, you can rmmod and modprobe the hdpvr
>> driver to pick up the change and then restart mythbackend or just
>> reboot the box.
> Ok, I added the options to my local.conf, rmmod hdpvr then modprobe
> hdpvr and checked the values by looking in /sys/module/hdpvr/parameters
> and they seem to have taken. I then did another cat /dev/video0 >
> test.ts and this time it would capture for 17-20 seconds (I tried
> several times) before the blue LED would go out. My backend has crappy
> Rage128 video, so I copied the files to my desktop, and they play fine,
> with audio.

Ok. That's a good sign that the HDPVR is not bad.

> I then unplugged the USB cable, turned the HDPVR off, plugged in the
> cable and turned it back on. I see the following from dmesg which looks
> ok to me:
>
> usb 1-1: new full speed USB device using uhci_hcd and address 46

This looks like a problem.  UHCI host controllers are limited to USB 1.x 
"full" and "low" speed devices.    You need a controller that is USB 2.0 or 
later to provide USB "high" speed.  If this motherboard does not have a EHCI 
USB controller on board, you'll need to get a USB PCI or PCIe card or move to 
a new motherboard that has a EHCI controller onboard.

If the motherboard does have a EHCI controller on board, make sure the EHCI 
driver is being loaded.  You could also check your BIOS settings to make sure 
the USB EHCI controller is enabled and/or USB 2.0 support is turned on.

If the EHCI driver is being loaded and lsusb shows USB 2.0 host controller 
hubs, then I'd suspect you may have a bad USB cable.  There's also a 
possibility that the controller chip has been damaged in some way.  Poor USB 
port designs are notorious for shorting out via static electricity.

> usb 1-1: New USB device found, idVendor=2040, idProduct=4902
> usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
> usb 1-1: Product: Hauppauge HD PVR
> usb 1-1: Manufacturer: AMBA
> usb 1-1: SerialNumber: 00A28B49
> usb 1-1: configuration #1 chosen from 1 choice
> hdpvr 1-1:1.0: untested firmware version 0x12, the driver might not work
> hdpvr 1-1:1.0: device now attached to /dev/video0

That looks normal.  The problem with that driver message is that it looks only 
at the version code and not the whole date string in the firmware version ID. 
  Hauppauge released several versions as beta with all the same ID and 
different dates.

You might not need to update the firmware, but if you need to you'll need to 
download the windows driver and attach the HDPVR to a computer running windows 
to update it.   This isn't really recommended unless you are having some kind 
of problem or happen to have a really old version of the firmware that doesn't 
support Dolby captures.  If you had a old version there would be a different 
message.  So I don't that's the case here.

> I tried capturing with cat again, and again I got about 17 seconds of
> capture, then the bright blue light went out and the file stopped
> growing. I dug around in the system log viewer and didn't see anything
> dmesg didn't give me.
> I then added the hdpvr_debug=1 to my local.conf and tried it again a
> couple of times, but I couldn't figure out which dmesg results were a
> product of which trials, so I rebooted the server.
>
> Trying again, I got about 15 seconds of capture, and dmesg showed this:
>
> hdpvr 1-1:1.0: config call request for value 0x700 returned 1
> hdpvr 1-1:1.0: config call request for value 0x800 returned 1
> hdpvr 1-1:1.0: transmit worker exited
>
> That didn't look very useful, so I guessed maybe the hddvr_debug number
> had some control over how much debug was displayed, so I changed it to
> 255 and rmmod and modprobed and tried again, got another 17 seconds of
> capture and dmesg had this:
> (I don't know what came before this, the scrollback buffer didn't go
> back that far)
> hdpvr 1-1:1.0: hdpvr_read:498 buffer stat: 1 free, 63 proc
> hdpvr 1-1:1.0: hdpvr_submit_buffers:205 buffer stat: 0 free, 64 proc
> (repeated many times)
> hdpvr 1-1:1.0: hdpvr_read:498 buffer stat: 1 free, 63 proc
> hdpvr 1-1:1.0: hdpvr_submit_buffers:205 buffer stat: 0 free, 64 proc
> hdpvr 1-1:1.0: config call request for value 0x800 returned 1
> hdpvr 1-1:1.0: transmit worker exited
> hdpvr 1-1:1.0: 1: got 8192 bytes
> hdpvr 1-1:1.0: 2: got 8192 bytes
> hdpvr 1-1:1.0: 3: got 8192 bytes
> hdpvr 1-1:1.0: 4: got 8192 bytes
> hdpvr 1-1:1.0: 5: got 8192 bytes
> hdpvr 1-1:1.0: 6: got 8192 bytes
> hdpvr 1-1:1.0: 7: got 8192 bytes
> hdpvr 1-1:1.0: 8: got 8192 bytes
> hdpvr 1-1:1.0: 9: got 8192 bytes
> hdpvr 1-1:1.0: 10: got 8192 bytes
> hdpvr 1-1:1.0: 11: got 8192 bytes
> hdpvr 1-1:1.0: 12: got 8192 bytes
> hdpvr 1-1:1.0: 13: got 8192 bytes
> hdpvr 1-1:1.0: 14: got 8192 bytes
> hdpvr 1-1:1.0: 15: got 8192 bytes
> hdpvr 1-1:1.0: 16: got 8192 bytes
> hdpvr 1-1:1.0: 17: got 8192 bytes
> hdpvr 1-1:1.0: 18: got 8192 bytes
> hdpvr 1-1:1.0: 19: got 8192 bytes
> hdpvr 1-1:1.0: 20: got 8192 bytes
> hdpvr 1-1:1.0: 21: got 8192 bytes
> hdpvr 1-1:1.0: 22: got 8192 bytes
> hdpvr 1-1:1.0: 23: got 8192 bytes
> hdpvr 1-1:1.0: 24: got 8192 bytes
> hdpvr 1-1:1.0: 25: got 8192 bytes
> hdpvr 1-1:1.0: 26: got 8192 bytes
> hdpvr 1-1:1.0: 27: got 8192 bytes
> hdpvr 1-1:1.0: 28: got 8192 bytes
> hdpvr 1-1:1.0: 29: got 8192 bytes
> hdpvr 1-1:1.0: 30: got 8192 bytes
> hdpvr 1-1:1.0: 31: got 8192 bytes
> hdpvr 1-1:1.0: 32: got 8192 bytes
> hdpvr 1-1:1.0: 33: got 8192 bytes
> hdpvr 1-1:1.0: 34: got 8192 bytes
> hdpvr 1-1:1.0: 35: got 8192 bytes
> hdpvr 1-1:1.0: 36: got 8192 bytes
> hdpvr 1-1:1.0: 37: got 8192 bytes
> hdpvr 1-1:1.0: 38: got 8192 bytes
> hdpvr 1-1:1.0: 39: got 8192 bytes
> hdpvr 1-1:1.0: 40: got 8192 bytes
> hdpvr 1-1:1.0: 41: got 8192 bytes
> hdpvr 1-1:1.0: 42: got 8192 bytes
> hdpvr 1-1:1.0: 43: got 8192 bytes
> hdpvr 1-1:1.0: 44: got 8192 bytes
> hdpvr 1-1:1.0: 45: got 8192 bytes
> hdpvr 1-1:1.0: 46: got 8192 bytes
> hdpvr 1-1:1.0: 47: got 8192 bytes
> hdpvr 1-1:1.0: 48: got 8192 bytes
> hdpvr 1-1:1.0: 49: got 8192 bytes
> hdpvr 1-1:1.0: used 49 urbs to empty device buffers

Yeah, currently only values >1 give information on buffer flow.  You'll get a 
lot of these during a capture.

> And that was it. I'm not sure where to go or what to try from here.
>

Check the controller info above and that should point you in the right direction.

Alan


More information about the mythtv-users mailing list