Mailing List Archive

HVR-1600 analog capture not working?
I have been trying in vain for weeks trying to get an HVR-1600 tuner card
to work in a new system I built (Intel mobo, Core i5, 8G RAM). It worked
fine in my old one but I'm not getting anything when I try to capture,
either with MythTV or directly cat'ing /dev/video > filename.mpg. I've
tried installing the same version of mythbuntu (10.04 w/2.6.32 kernel) that
I have on my working system but the motherboard is too new to get network
support in that kernel (so installing all the various dependencies for
ivtv-utils appears to be incredibly difficult).
Any suggestions? I am not seeing anything in kernel log right now
suggesting a direction to go.

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
Here are some instructions that Andy helped me with some time back that I think will be of help. I think I will actually put this to my blog in the near future too. Hope this helps as basically you will want to identify where your tuner really is and make sure it is using the right standard.

You may have to write some udev rules to help out after you have it figured out. Recently I found my dev folders wandering a little. To help you there you can go to the following link for a blog entry that I did on the matter. http://petersopus.wordpress.com/2012/06/18/cure-for-the-drifting-dev-folder/

Thanks,
Peter

>> Please install v4l2-ctl (probably in a v4l2-utils package) and mplayer.
>>
>> Kill the mythbackend, if it is running.
>>
>> Then run v4l2-ctl --list-devices, to see what card corresponds to which
>> devices nodes. For example:
>>
>> $ v4l2-ctl --list-devices
>> Hauppauge HVR-1600 (PCI:0000:03:00.0):
>> /dev/video0
>> /dev/video24
>> /dev/video32
>> /dev/vbi0
>>
>> Hauppauge WinTV PVR-150 (PCI:0000:03:01.0):
>> /dev/video2
>> /dev/video26
>> /dev/video34
>> /dev/radio2
>> /dev/vbi2
>>
>> Hauppauge HVR-1600 (PCI:0000:03:02.0):
>> /dev/video1
>> /dev/video25
>> /dev/video33
>> /dev/radio1
>> /dev/vbi1
>>
>> On a device from which you wish to capture S-Video, set the proper input
>> and analog TV standard using v4l2-ctl:
>>
>> $ v4l2-ctl -d /dev/video0 --list-inputs
>> ioctl: VIDIOC_ENUMINPUT
>> Input : 0
>> Name : Tuner 1
>> Type : 0x00000001
>> Audioset : 0x00000007
>> Tuner : 0x00000000
>> Standard : 0x0000000000001000 (NTSC-M)
>> Status : 0x00000000 (ok)
>> Capabilities: 0x00000004 (SD presets)
>>
>> Input : 1
>> Name : S-Video 1
>> Type : 0x00000002
>> Audioset : 0x00000007
>> Tuner : 0x00000000
>> Standard : 0x0000000000FFFFFF (PAL-B/B1/G/H/I/D/D1/K/M/N/Nc/60 NTSC-M/M-JP/443/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
>> Status : 0x00000000 (ok)
>> Capabilities: 0x00000004 (SD presets)
>>
>> Input : 2
>> Name : Composite 1
>> Type : 0x00000002
>> Audioset : 0x00000007
>> Tuner : 0x00000000
>> Standard : 0x0000000000FFFFFF (PAL-B/B1/G/H/I/D/D1/K/M/N/Nc/60 NTSC-M/M-JP/443/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
>> Status : 0x00000000 (ok)
>> Capabilities: 0x00000004 (SD presets)
>> [...]
>>
>> $ v4l2-ctl -d /dev/video0 --set-input=1
>> Video input set to 1 (S-Video 1: ok)
>>
>> $ v4l2-ctl -d /dev/video0 --list-standards
>> ioctl: VIDIOC_ENUMSTD
>> Index : 0
>> ID : 0x000000000000B000
>> Name : NTSC
>> Frame period: 1001/30000
>> Frame lines : 525
>>
>> Index : 1
>> ID : 0x0000000000001000
>> Name : NTSC-M
>> Frame period: 1001/30000
>> Frame lines : 525
>> [...]
>>
>> $ v4l2-ctl -d /dev/video0 --set-standard=1
>> Standard set to 00001000
>>
>>
>> Turn on your S-Video source, and then just capture an MPEG live with mplayer:
>>
>> $ mplayer /dev/video0 -cache 8192
>>
>> or capture a file for later playback
>>
>> $ cat /dev/video0 > foo.mpg
>> ^C
>> $ mplayer foo.mpg
>>
>>
>>
>>> Here is what I see on the two problematic analog tuners.
>>
>> Looks like an untuned tuner input driving the encoder, not S-Video. An
>> S-Video input that is connected but has no signal is usually a solid
>> grey or black screen.
>>

>> One last step is to verify that you do in fact have a video signal with
>> a known good devices (such as a TV). If you have RF analog or RF
>> digital reception problems, you may want to review this checklist as
>> well:
>>
>> http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
>>
>> Regards,
>> Andy





On 2012-06-27, at 10:53 AM, Robert Rust wrote:

> I have been trying in vain for weeks trying to get an HVR-1600 tuner card to work in a new system I built (Intel mobo, Core i5, 8G RAM). It worked fine in my old one but I'm not getting anything when I try to capture, either with MythTV or directly cat'ing /dev/video > filename.mpg. I've tried installing the same version of mythbuntu (10.04 w/2.6.32 kernel) that I have on my working system but the motherboard is too new to get network support in that kernel (so installing all the various dependencies for ivtv-utils appears to be incredibly difficult).
> Any suggestions? I am not seeing anything in kernel log right now suggesting a direction to go.
>
> -Robert
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
I'm trying to capture off the analog tuner (input 0) and that's already set
to the correct standard (NTSC-M). It looks like I can tune with ivtv-ctl,
as I get "Signal Detected" on channels I receive ... but dumping to a file
or mplayer still results in nothing (mplayer caching never progresses).

-Robert

p.s. is top-posting the preferred response method on this list? I know
it's frowned-upon elsewhere.

On Wed, Jun 27, 2012 at 12:07 PM, Peter Schneider <
peter.schneider@schneideris.com> wrote:

> Here are some instructions that Andy helped me with some time back that I
> think will be of help. I think I will actually put this to my blog in the
> near future too. Hope this helps as basically you will want to identify
> where your tuner really is and make sure it is using the right standard.
>
> You may have to write some udev rules to help out after you have it
> figured out. Recently I found my dev folders wandering a little. To help
> you there you can go to the following link for a blog entry that I did on
> the matter.
> http://petersopus.wordpress.com/2012/06/18/cure-for-the-drifting-dev-folder/
>
> Thanks,
> Peter
>
> Please install v4l2-ctl (probably in a v4l2-utils package) and mplayer.
>
>
> Kill the mythbackend, if it is running.
>
>
> Then run v4l2-ctl --list-devices, to see what card corresponds to which
>
> devices nodes. For example:
>
>
> $ v4l2-ctl --list-devices
>
> Hauppauge HVR-1600 (PCI:0000:03:00.0):
>
> /dev/video0
>
> /dev/video24
>
> /dev/video32
>
> /dev/vbi0
>
>
> Hauppauge WinTV PVR-150 (PCI:0000:03:01.0):
>
> /dev/video2
>
> /dev/video26
>
> /dev/video34
>
> /dev/radio2
>
> /dev/vbi2
>
>
> Hauppauge HVR-1600 (PCI:0000:03:02.0):
>
> /dev/video1
>
> /dev/video25
>
> /dev/video33
>
> /dev/radio1
>
> /dev/vbi1
>
>
> On a device from which you wish to capture S-Video, set the proper input
>
> and analog TV standard using v4l2-ctl:
>
>
> $ v4l2-ctl -d /dev/video0 --list-inputs
>
> ioctl: VIDIOC_ENUMINPUT
>
> Input : 0
>
> Name : Tuner 1
>
> Type : 0x00000001
>
> Audioset : 0x00000007
>
> Tuner : 0x00000000
>
> Standard : 0x0000000000001000 (NTSC-M)
>
> Status : 0x00000000 (ok)
>
> Capabilities: 0x00000004 (SD presets)
>
>
> Input : 1
>
> Name : S-Video 1
>
> Type : 0x00000002
>
> Audioset : 0x00000007
>
> Tuner : 0x00000000
>
> Standard : 0x0000000000FFFFFF (PAL-B/B1/G/H/I/D/D1/K/M/N/Nc/60
> NTSC-M/M-JP/443/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
>
> Status : 0x00000000 (ok)
>
> Capabilities: 0x00000004 (SD presets)
>
>
> Input : 2
>
> Name : Composite 1
>
> Type : 0x00000002
>
> Audioset : 0x00000007
>
> Tuner : 0x00000000
>
> Standard : 0x0000000000FFFFFF (PAL-B/B1/G/H/I/D/D1/K/M/N/Nc/60
> NTSC-M/M-JP/443/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
>
> Status : 0x00000000 (ok)
>
> Capabilities: 0x00000004 (SD presets)
>
> [...]
>
>
> $ v4l2-ctl -d /dev/video0 --set-input=1
>
> Video input set to 1 (S-Video 1: ok)
>
>
> $ v4l2-ctl -d /dev/video0 --list-standards
>
> ioctl: VIDIOC_ENUMSTD
>
> Index : 0
>
> ID : 0x000000000000B000
>
> Name : NTSC
>
> Frame period: 1001/30000
>
> Frame lines : 525
>
>
> Index : 1
>
> ID : 0x0000000000001000
>
> Name : NTSC-M
>
> Frame period: 1001/30000
>
> Frame lines : 525
>
> [...]
>
>
> $ v4l2-ctl -d /dev/video0 --set-standard=1
>
> Standard set to 00001000
>
>
>
> Turn on your S-Video source, and then just capture an MPEG live with
> mplayer:
>
>
> $ mplayer /dev/video0 -cache 8192
>
>
> or capture a file for later playback
>
>
> $ cat /dev/video0 > foo.mpg
>
> ^C
>
> $ mplayer foo.mpg
>
>
>
>
> Here is what I see on the two problematic analog tuners.
>
>
> Looks like an untuned tuner input driving the encoder, not S-Video. An
>
> S-Video input that is connected but has no signal is usually a solid
>
> grey or black screen.
>
>
>
> One last step is to verify that you do in fact have a video signal with
>
> a known good devices (such as a TV). If you have RF analog or RF
>
> digital reception problems, you may want to review this checklist as
>
> well:
>
>
> http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
>
>
> Regards,
>
> Andy
>
>
>
>
>
> On 2012-06-27, at 10:53 AM, Robert Rust wrote:
>
> I have been trying in vain for weeks trying to get an HVR-1600 tuner card
> to work in a new system I built (Intel mobo, Core i5, 8G RAM). It worked
> fine in my old one but I'm not getting anything when I try to capture,
> either with MythTV or directly cat'ing /dev/video > filename.mpg. I've
> tried installing the same version of mythbuntu (10.04 w/2.6.32 kernel) that
> I have on my working system but the motherboard is too new to get network
> support in that kernel (so installing all the various dependencies for
> ivtv-utils appears to be incredibly difficult).
> Any suggestions? I am not seeing anything in kernel log right now
> suggesting a direction to go.
>
> -Robert
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
Re: HVR-1600 analog capture not working? [ In reply to ]
Sorry to say but I am not likely much more help here. To me it does not look promising as there may be a dead card if you get a signal detected and then no actual image.

Thanks,
Peter




On 2012-06-27, at 12:21 PM, Robert Rust wrote:

> I'm trying to capture off the analog tuner (input 0) and that's already set to the correct standard (NTSC-M). It looks like I can tune with ivtv-ctl, as I get "Signal Detected" on channels I receive ... but dumping to a file or mplayer still results in nothing (mplayer caching never progresses).
>
> -Robert
>
> p.s. is top-posting the preferred response method on this list? I know it's frowned-upon elsewhere.
>
> On Wed, Jun 27, 2012 at 12:07 PM, Peter Schneider <peter.schneider@schneideris.com> wrote:
> Here are some instructions that Andy helped me with some time back that I think will be of help. I think I will actually put this to my blog in the near future too. Hope this helps as basically you will want to identify where your tuner really is and make sure it is using the right standard.
>
> You may have to write some udev rules to help out after you have it figured out. Recently I found my dev folders wandering a little. To help you there you can go to the following link for a blog entry that I did on the matter. http://petersopus.wordpress.com/2012/06/18/cure-for-the-drifting-dev-folder/
>
> Thanks,
> Peter
>
>>> Please install v4l2-ctl (probably in a v4l2-utils package) and mplayer.
>>>
>>> Kill the mythbackend, if it is running.
>>>
>>> Then run v4l2-ctl --list-devices, to see what card corresponds to which
>>> devices nodes. For example:
>>>
>>> $ v4l2-ctl --list-devices
>>> Hauppauge HVR-1600 (PCI:0000:03:00.0):
>>> /dev/video0
>>> /dev/video24
>>> /dev/video32
>>> /dev/vbi0
>>>
>>> Hauppauge WinTV PVR-150 (PCI:0000:03:01.0):
>>> /dev/video2
>>> /dev/video26
>>> /dev/video34
>>> /dev/radio2
>>> /dev/vbi2
>>>
>>> Hauppauge HVR-1600 (PCI:0000:03:02.0):
>>> /dev/video1
>>> /dev/video25
>>> /dev/video33
>>> /dev/radio1
>>> /dev/vbi1
>>>
>>> On a device from which you wish to capture S-Video, set the proper input
>>> and analog TV standard using v4l2-ctl:
>>>
>>> $ v4l2-ctl -d /dev/video0 --list-inputs
>>> ioctl: VIDIOC_ENUMINPUT
>>> Input : 0
>>> Name : Tuner 1
>>> Type : 0x00000001
>>> Audioset : 0x00000007
>>> Tuner : 0x00000000
>>> Standard : 0x0000000000001000 (NTSC-M)
>>> Status : 0x00000000 (ok)
>>> Capabilities: 0x00000004 (SD presets)
>>>
>>> Input : 1
>>> Name : S-Video 1
>>> Type : 0x00000002
>>> Audioset : 0x00000007
>>> Tuner : 0x00000000
>>> Standard : 0x0000000000FFFFFF (PAL-B/B1/G/H/I/D/D1/K/M/N/Nc/60 NTSC-M/M-JP/443/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
>>> Status : 0x00000000 (ok)
>>> Capabilities: 0x00000004 (SD presets)
>>>
>>> Input : 2
>>> Name : Composite 1
>>> Type : 0x00000002
>>> Audioset : 0x00000007
>>> Tuner : 0x00000000
>>> Standard : 0x0000000000FFFFFF (PAL-B/B1/G/H/I/D/D1/K/M/N/Nc/60 NTSC-M/M-JP/443/M-KR SECAM-B/D/G/H/K/K1/L/Lc)
>>> Status : 0x00000000 (ok)
>>> Capabilities: 0x00000004 (SD presets)
>>> [...]
>>>
>>> $ v4l2-ctl -d /dev/video0 --set-input=1
>>> Video input set to 1 (S-Video 1: ok)
>>>
>>> $ v4l2-ctl -d /dev/video0 --list-standards
>>> ioctl: VIDIOC_ENUMSTD
>>> Index : 0
>>> ID : 0x000000000000B000
>>> Name : NTSC
>>> Frame period: 1001/30000
>>> Frame lines : 525
>>>
>>> Index : 1
>>> ID : 0x0000000000001000
>>> Name : NTSC-M
>>> Frame period: 1001/30000
>>> Frame lines : 525
>>> [...]
>>>
>>> $ v4l2-ctl -d /dev/video0 --set-standard=1
>>> Standard set to 00001000
>>>
>>>
>>> Turn on your S-Video source, and then just capture an MPEG live with mplayer:
>>>
>>> $ mplayer /dev/video0 -cache 8192
>>>
>>> or capture a file for later playback
>>>
>>> $ cat /dev/video0 > foo.mpg
>>> ^C
>>> $ mplayer foo.mpg
>>>
>>>
>>>
>>>> Here is what I see on the two problematic analog tuners.
>>>
>>> Looks like an untuned tuner input driving the encoder, not S-Video. An
>>> S-Video input that is connected but has no signal is usually a solid
>>> grey or black screen.
>>>
>
>>> One last step is to verify that you do in fact have a video signal with
>>> a known good devices (such as a TV). If you have RF analog or RF
>>> digital reception problems, you may want to review this checklist as
>>> well:
>>>
>>> http://ivtvdriver.org/index.php/Howto:Improve_signal_quality
>>>
>>> Regards,
>>> Andy
>
>
>
>
>
> On 2012-06-27, at 10:53 AM, Robert Rust wrote:
>
>> I have been trying in vain for weeks trying to get an HVR-1600 tuner card to work in a new system I built (Intel mobo, Core i5, 8G RAM). It worked fine in my old one but I'm not getting anything when I try to capture, either with MythTV or directly cat'ing /dev/video > filename.mpg. I've tried installing the same version of mythbuntu (10.04 w/2.6.32 kernel) that I have on my working system but the motherboard is too new to get network support in that kernel (so installing all the various dependencies for ivtv-utils appears to be incredibly difficult).
>> Any suggestions? I am not seeing anything in kernel log right now suggesting a direction to go.
>>
>> -Robert
>> _______________________________________________
>> ivtv-users mailing list
>> ivtv-users@ivtvdriver.org
>> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
<peter.schneider@schneideris.com> wrote:
> Sorry to say but I am not likely much more help here.  To me it does not
> look promising as there may be a dead card if you get a signal detected and
> then no actual image.
>
> Thanks,
> Peter

There are numerous alternatives to it being a dead card.

Is the firmware installed? Any errors in dmesg?

Are you interacting with /dev/video0 or /dev/video1? You might be
trying to read the raw video device, which won't work properly in
mplayer without extra arguments.

Have you tried catting the /dev/video0 to a file and see if it is
non-zero length?

Note you should be sure the mythbackend is stopped before doing any of this.

Devin

--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
dheitmueller@kernellabs.com> wrote:

> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
> <peter.schneider@schneideris.com> wrote:
> > Sorry to say but I am not likely much more help here. To me it does not
> > look promising as there may be a dead card if you get a signal detected
> and
> > then no actual image.
> >
> > Thanks,
> > Peter
>
> There are numerous alternatives to it being a dead card.
>
> Is the firmware installed? Any errors in dmesg?
>
> Are you interacting with /dev/video0 or /dev/video1? You might be
> trying to read the raw video device, which won't work properly in
> mplayer without extra arguments.
>
> Have you tried catting the /dev/video0 to a file and see if it is
> non-zero length?
>
> Note you should be sure the mythbackend is stopped before doing any of
> this.
>
> Devin
>
> Firmware is installed. No errors. I've tried both using mplayer and
dumping to a file. The file dump resulted in a 0 byte file (which is how I
ruled out the MythTV software as the problem). I did stop mythbackend.
I've even gone so far as to replicate this problem on a fairly bare-bones
Ubuntu 12.04 server install (which wouldn't have any of the MythTV bits).

The signal should be good strength as it's coming straight out of the wall
(unity gain distribution amplifier to ensure that). I'll post my "dmesg |
grep cx18" below, but have noted that the version listed (1.5.1) is
significantly newer than what I had in my old system (1.2.0), which is why
I was experimenting with the Ubuntu 10.0.4 install (I now have 10, 11 and
12 side-by-side on the new hardware).

[ 6.449510] cx18: Start initialization, version 1.5.1
[ 6.449542] cx18-0: Initializing card 0
[ 6.449543] cx18-0: Autodetected Hauppauge card
[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64 (was
32)
[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture supported
[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64 x
32.00 kB)
[ 7.073040] DVB: registering new adapter (cx18)
[ 7.249671] cx18-0: DVB Frontend registered
[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20 x
101.25 kB)
[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984
bytes)
[ 7.249749] cx18-0: Registered device video24 for encoder PCM audio (256
x 4.00 kB)
[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
[ 7.249786] cx18: End initialization
[ 7.441838] cx18-alsa: module loading...
[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200
bytes)
[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware
(16382 bytes)
Re: HVR-1600 analog capture not working? [ In reply to ]
Something that just came to mind. When I did a patch recently I had everything broken as a result. Doing some Google searches turned up an instruction for a GIT install of the drivers and then downloading of the firmware fresh from I think the IVTV site. The instructions identified that the firmware that had been with the driver was flawed at the time of the post having been written. You might try finding the post and walking through those steps. Sorry I can't remember or find the post right now.

Thanks,
Peter




On 2012-06-27, at 12:51 PM, Robert Rust wrote:

> On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <dheitmueller@kernellabs.com> wrote:
> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
> <peter.schneider@schneideris.com> wrote:
> > Sorry to say but I am not likely much more help here. To me it does not
> > look promising as there may be a dead card if you get a signal detected and
> > then no actual image.
> >
> > Thanks,
> > Peter
>
> There are numerous alternatives to it being a dead card.
>
> Is the firmware installed? Any errors in dmesg?
>
> Are you interacting with /dev/video0 or /dev/video1? You might be
> trying to read the raw video device, which won't work properly in
> mplayer without extra arguments.
>
> Have you tried catting the /dev/video0 to a file and see if it is
> non-zero length?
>
> Note you should be sure the mythbackend is stopped before doing any of this.
>
> Devin
>
> Firmware is installed. No errors. I've tried both using mplayer and dumping to a file. The file dump resulted in a 0 byte file (which is how I ruled out the MythTV software as the problem). I did stop mythbackend. I've even gone so far as to replicate this problem on a fairly bare-bones Ubuntu 12.04 server install (which wouldn't have any of the MythTV bits).
>
> The signal should be good strength as it's coming straight out of the wall (unity gain distribution amplifier to ensure that). I'll post my "dmesg | grep cx18" below, but have noted that the version listed (1.5.1) is significantly newer than what I had in my old system (1.2.0), which is why I was experimenting with the Ubuntu 10.0.4 install (I now have 10, 11 and 12 side-by-side on the new hardware).
>
> [ 6.449510] cx18: Start initialization, version 1.5.1
> [ 6.449542] cx18-0: Initializing card 0
> [ 6.449543] cx18-0: Autodetected Hauppauge card
> [ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
> [ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64 (was 32)
> [ 6.461752] cx18-0: cx23418 revision 01010000 (B)
> [ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
> [ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture supported
> [ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> [ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64 x 32.00 kB)
> [ 7.073040] DVB: registering new adapter (cx18)
> [ 7.249671] cx18-0: DVB Frontend registered
> [ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
> [ 7.249701] cx18-0: Registered device video32 for encoder YUV (20 x 101.25 kB)
> [ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x 51984 bytes)
> [ 7.249749] cx18-0: Registered device video24 for encoder PCM audio (256 x 4.00 kB)
> [ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
> [ 7.249786] cx18: End initialization
> [ 7.441838] cx18-alsa: module loading...
> [ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332 bytes)
> [ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000 (141200 bytes)
> [ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> [ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382 bytes)
> [ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware (16382 bytes)
>
> _______________________________________________
> ivtv-users mailing list
> ivtv-users@ivtvdriver.org
> http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
Robert Rust <rjrbytes@gmail.com> wrote:

>On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
>dheitmueller@kernellabs.com> wrote:
>
>> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
>> <peter.schneider@schneideris.com> wrote:
>> > Sorry to say but I am not likely much more help here. To me it
>does not
>> > look promising as there may be a dead card if you get a signal
>detected
>> and
>> > then no actual image.
>> >
>> > Thanks,
>> > Peter
>>
>> There are numerous alternatives to it being a dead card.
>>
>> Is the firmware installed? Any errors in dmesg?
>>
>> Are you interacting with /dev/video0 or /dev/video1? You might be
>> trying to read the raw video device, which won't work properly in
>> mplayer without extra arguments.
>>
>> Have you tried catting the /dev/video0 to a file and see if it is
>> non-zero length?
>>
>> Note you should be sure the mythbackend is stopped before doing any
>of
>> this.
>>
>> Devin
>>
>> Firmware is installed. No errors. I've tried both using mplayer and
>dumping to a file. The file dump resulted in a 0 byte file (which is
>how I
>ruled out the MythTV software as the problem). I did stop mythbackend.
>I've even gone so far as to replicate this problem on a fairly
>bare-bones
>Ubuntu 12.04 server install (which wouldn't have any of the MythTV
>bits).
>
>The signal should be good strength as it's coming straight out of the
>wall
>(unity gain distribution amplifier to ensure that). I'll post my
>"dmesg |
>grep cx18" below, but have noted that the version listed (1.5.1) is
>significantly newer than what I had in my old system (1.2.0), which is
>why
>I was experimenting with the Ubuntu 10.0.4 install (I now have 10, 11
>and
>12 side-by-side on the new hardware).
>
>[ 6.449510] cx18: Start initialization, version 1.5.1
>[ 6.449542] cx18-0: Initializing card 0
>[ 6.449543] cx18-0: Autodetected Hauppauge card
>[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low) ->
>IRQ 17
>[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64
>(was
>32)
>[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
>[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
>[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture
>supported
>[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
>[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64 x
>32.00 kB)
>[ 7.073040] DVB: registering new adapter (cx18)
>[ 7.249671] cx18-0: DVB Frontend registered
>[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
>[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20 x
>101.25 kB)
>[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x
>51984
>bytes)
>[ 7.249749] cx18-0: Registered device video24 for encoder PCM audio
>(256
>x 4.00 kB)
>[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
>[ 7.249786] cx18: End initialization
>[ 7.441838] cx18-alsa: module loading...
>[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332
>bytes)
>[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
>(141200
>bytes)
>[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
>[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382
>bytes)
>[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware
>(16382 bytes)
>_______________________________________________
>ivtv-users mailing list
>ivtv-users@ivtvdriver.org
>http://ivtvdriver.org/mailman/listinfo/ivtv-users

Hi Robert,

Start a capture (cat /dev/video0 > foo.mpg ) and then cat /proc/interrupts . You should see the interrupts handled for the cx18 driver increasing.

If not, then add a debug=0x1ff to the cx18 module options when loading the module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and try another capture. You should get lots of debug in /var/log/messages which might give insight into the problem.

And for the record, top-posting is _not_ preferred. But in an era of lame smartphone email clients it is forgivable. ;)

Regards,
Andy

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls <awalls@md.metrocast.net> wrote:

> Robert Rust <rjrbytes@gmail.com> wrote:
>
> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
> >dheitmueller@kernellabs.com> wrote:
> >
> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
> >> <peter.schneider@schneideris.com> wrote:
> >> > Sorry to say but I am not likely much more help here. To me it
> >does not
> >> > look promising as there may be a dead card if you get a signal
> >detected
> >> and
> >> > then no actual image.
> >> >
> >> > Thanks,
> >> > Peter
> >>
> >> There are numerous alternatives to it being a dead card.
> >>
> >> Is the firmware installed? Any errors in dmesg?
> >>
> >> Are you interacting with /dev/video0 or /dev/video1? You might be
> >> trying to read the raw video device, which won't work properly in
> >> mplayer without extra arguments.
> >>
> >> Have you tried catting the /dev/video0 to a file and see if it is
> >> non-zero length?
> >>
> >> Note you should be sure the mythbackend is stopped before doing any
> >of
> >> this.
> >>
> >> Devin
> >>
> >> Firmware is installed. No errors. I've tried both using mplayer and
> >dumping to a file. The file dump resulted in a 0 byte file (which is
> >how I
> >ruled out the MythTV software as the problem). I did stop mythbackend.
> >I've even gone so far as to replicate this problem on a fairly
> >bare-bones
> >Ubuntu 12.04 server install (which wouldn't have any of the MythTV
> >bits).
> >
> >The signal should be good strength as it's coming straight out of the
> >wall
> >(unity gain distribution amplifier to ensure that). I'll post my
> >"dmesg |
> >grep cx18" below, but have noted that the version listed (1.5.1) is
> >significantly newer than what I had in my old system (1.2.0), which is
> >why
> >I was experimenting with the Ubuntu 10.0.4 install (I now have 10, 11
> >and
> >12 side-by-side on the new hardware).
> >
> >[ 6.449510] cx18: Start initialization, version 1.5.1
> >[ 6.449542] cx18-0: Initializing card 0
> >[ 6.449543] cx18-0: Autodetected Hauppauge card
> >[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low) ->
> >IRQ 17
> >[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64
> >(was
> >32)
> >[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
> >[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
> >[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture
> >supported
> >[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
> >[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64 x
> >32.00 kB)
> >[ 7.073040] DVB: registering new adapter (cx18)
> >[ 7.249671] cx18-0: DVB Frontend registered
> >[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00 kB)
> >[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20 x
> >101.25 kB)
> >[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x
> >51984
> >bytes)
> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM audio
> >(256
> >x 4.00 kB)
> >[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
> >[ 7.249786] cx18: End initialization
> >[ 7.441838] cx18-alsa: module loading...
> >[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332
> >bytes)
> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
> >(141200
> >bytes)
> >[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> >[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382
> >bytes)
> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware
> >(16382 bytes)
> >_______________________________________________
> >ivtv-users mailing list
> >ivtv-users@ivtvdriver.org
> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> Hi Robert,
>
> Start a capture (cat /dev/video0 > foo.mpg ) and then cat /proc/interrupts
> . You should see the interrupts handled for the cx18 driver increasing.
>
> If not, then add a debug=0x1ff to the cx18 module options when loading the
> module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and try
> another capture. You should get lots of debug in /var/log/messages which
> might give insight into the problem.
>
> And for the record, top-posting is _not_ preferred. But in an era of lame
> smartphone email clients it is forgivable. ;)
>
> Regards,
> Andy
>
>
That certainly provided a lot of additional messages, though from what I've
read, some may be normal, e.g.:
[ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send
CX18_CPU_DE_SET_MDL
[ 454.868754] cx18-0: warning: failed to be awakened upon RPU
acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12 msecs
[ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005 args
0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000

I'm not sure what constitutes a problem. I'd post log output but it's
about 650 lines from when I modprobed with debug to when I ended capture.
Should I go ahead and send it?

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
>
> Hi Robert,
>>
>> Start a capture (cat /dev/video0 > foo.mpg ) and then cat
>> /proc/interrupts . You should see the interrupts handled for the cx18
>> driver increasing.
>>
>> If not, then add a debug=0x1ff to the cx18 module options when loading
>> the module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and
>> try another capture. You should get lots of debug in /var/log/messages
>> which might give insight into the problem.
>>
>> And for the record, top-posting is _not_ preferred. But in an era of
>> lame smartphone email clients it is forgivable. ;)
>>
>> Regards,
>> Andy
>>
>>
> That certainly provided a lot of additional messages, though from what
> I've read, some may be normal, e.g.:
> [ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send
> CX18_CPU_DE_SET_MDL
> [ 454.868754] cx18-0: warning: failed to be awakened upon RPU
> acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12 msecs
> [ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005 args
> 0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000
>
> I'm not sure what constitutes a problem. I'd post log output but it's
> about 650 lines from when I modprobed with debug to when I ended capture.
> Should I go ahead and send it?
>
> -Robert
>

Possibly relevant ... appeared after ending the capture:
[ 492.889079] cx18-0: info: User stopped encoder MPEG
[ 492.889084] cx18-0: file: read 32768 from encoder MPEG, got -4
[ 492.889146] cx18-0: ioctl: close() of encoder MPEG
[ 492.889150] cx18-0: ioctl: close() of encoder MPEG
[ 492.889152] cx18-0: info: close stopping capture
[ 492.889154] cx18-0: info: close stopping IDX capture
[ 492.889156] cx18-0: info: Stop Capture

That's definitely not all that's in there, but the particular line that
looks unusual to me is the "file: read 32768 ..."

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
Robert Rust <rjrbytes@gmail.com> wrote:

>On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls <awalls@md.metrocast.net>
>wrote:
>
>> Robert Rust <rjrbytes@gmail.com> wrote:
>>
>> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
>> >dheitmueller@kernellabs.com> wrote:
>> >
>> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
>> >> <peter.schneider@schneideris.com> wrote:
>> >> > Sorry to say but I am not likely much more help here. To me it
>> >does not
>> >> > look promising as there may be a dead card if you get a signal
>> >detected
>> >> and
>> >> > then no actual image.
>> >> >
>> >> > Thanks,
>> >> > Peter
>> >>
>> >> There are numerous alternatives to it being a dead card.
>> >>
>> >> Is the firmware installed? Any errors in dmesg?
>> >>
>> >> Are you interacting with /dev/video0 or /dev/video1? You might be
>> >> trying to read the raw video device, which won't work properly in
>> >> mplayer without extra arguments.
>> >>
>> >> Have you tried catting the /dev/video0 to a file and see if it is
>> >> non-zero length?
>> >>
>> >> Note you should be sure the mythbackend is stopped before doing
>any
>> >of
>> >> this.
>> >>
>> >> Devin
>> >>
>> >> Firmware is installed. No errors. I've tried both using mplayer
>and
>> >dumping to a file. The file dump resulted in a 0 byte file (which
>is
>> >how I
>> >ruled out the MythTV software as the problem). I did stop
>mythbackend.
>> >I've even gone so far as to replicate this problem on a fairly
>> >bare-bones
>> >Ubuntu 12.04 server install (which wouldn't have any of the MythTV
>> >bits).
>> >
>> >The signal should be good strength as it's coming straight out of
>the
>> >wall
>> >(unity gain distribution amplifier to ensure that). I'll post my
>> >"dmesg |
>> >grep cx18" below, but have noted that the version listed (1.5.1) is
>> >significantly newer than what I had in my old system (1.2.0), which
>is
>> >why
>> >I was experimenting with the Ubuntu 10.0.4 install (I now have 10,
>11
>> >and
>> >12 side-by-side on the new hardware).
>> >
>> >[ 6.449510] cx18: Start initialization, version 1.5.1
>> >[ 6.449542] cx18-0: Initializing card 0
>> >[ 6.449543] cx18-0: Autodetected Hauppauge card
>> >[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low)
>->
>> >IRQ 17
>> >[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64
>> >(was
>> >32)
>> >[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
>> >[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
>> >[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture
>> >supported
>> >[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver
>#0-0)
>> >[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64
>x
>> >32.00 kB)
>> >[ 7.073040] DVB: registering new adapter (cx18)
>> >[ 7.249671] cx18-0: DVB Frontend registered
>> >[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00
>kB)
>> >[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20
>x
>> >101.25 kB)
>> >[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x
>> >51984
>> >bytes)
>> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM
>audio
>> >(256
>> >x 4.00 kB)
>> >[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
>> >[ 7.249786] cx18: End initialization
>> >[ 7.441838] cx18-alsa: module loading...
>> >[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332
>> >bytes)
>> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
>> >(141200
>> >bytes)
>> >[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
>> >[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382
>> >bytes)
>> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw
>firmware
>> >(16382 bytes)
>> >_______________________________________________
>> >ivtv-users mailing list
>> >ivtv-users@ivtvdriver.org
>> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>
>> Hi Robert,
>>
>> Start a capture (cat /dev/video0 > foo.mpg ) and then cat
>/proc/interrupts
>> . You should see the interrupts handled for the cx18 driver
>increasing.
>>
>> If not, then add a debug=0x1ff to the cx18 module options when
>loading the
>> module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and
>try
>> another capture. You should get lots of debug in /var/log/messages
>which
>> might give insight into the problem.
>>
>> And for the record, top-posting is _not_ preferred. But in an era of
>lame
>> smartphone email clients it is forgivable. ;)
>>
>> Regards,
>> Andy
>>
>>
>That certainly provided a lot of additional messages, though from what
>I've
>read, some may be normal, e.g.:
>[ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send
>CX18_CPU_DE_SET_MDL
>[ 454.868754] cx18-0: warning: failed to be awakened upon RPU
>acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12 msecs
>[ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005 args
>0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000
>
>I'm not sure what constitutes a problem. I'd post log output but it's
>about 650 lines from when I modprobed with debug to when I ended
>capture.
>Should I go ahead and send it?
>
>-Robert
>_______________________________________________
>ivtv-users mailing list
>ivtv-users@ivtvdriver.org
>http://ivtvdriver.org/mailman/listinfo/ivtv-users

Hi Robert,

Sending it to the list if you want. If it bounces, you can send it directly to me.

From the one message set you culled it seems very likely that interrupts from the CX23418 chip are not being processed by the cx18 driver's IRQ irq handler.

This is likely a system level issue. What other drivers share the irq lines with the cx18 driver? See the output of cat /proc/interrupts.

Regards,
Andy

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
On Wed, Jun 27, 2012 at 5:01 PM, Andy Walls <awalls@md.metrocast.net> wrote:

> Robert Rust <rjrbytes@gmail.com> wrote:
>
> >On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls <awalls@md.metrocast.net>
> >wrote:
> >
> >> Robert Rust <rjrbytes@gmail.com> wrote:
> >>
> >> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
> >> >dheitmueller@kernellabs.com> wrote:
> >> >
> >> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
> >> >> <peter.schneider@schneideris.com> wrote:
> >> >> > Sorry to say but I am not likely much more help here. To me it
> >> >does not
> >> >> > look promising as there may be a dead card if you get a signal
> >> >detected
> >> >> and
> >> >> > then no actual image.
> >> >> >
> >> >> > Thanks,
> >> >> > Peter
> >> >>
> >> >> There are numerous alternatives to it being a dead card.
> >> >>
> >> >> Is the firmware installed? Any errors in dmesg?
> >> >>
> >> >> Are you interacting with /dev/video0 or /dev/video1? You might be
> >> >> trying to read the raw video device, which won't work properly in
> >> >> mplayer without extra arguments.
> >> >>
> >> >> Have you tried catting the /dev/video0 to a file and see if it is
> >> >> non-zero length?
> >> >>
> >> >> Note you should be sure the mythbackend is stopped before doing
> >any
> >> >of
> >> >> this.
> >> >>
> >> >> Devin
> >> >>
> >> >> Firmware is installed. No errors. I've tried both using mplayer
> >and
> >> >dumping to a file. The file dump resulted in a 0 byte file (which
> >is
> >> >how I
> >> >ruled out the MythTV software as the problem). I did stop
> >mythbackend.
> >> >I've even gone so far as to replicate this problem on a fairly
> >> >bare-bones
> >> >Ubuntu 12.04 server install (which wouldn't have any of the MythTV
> >> >bits).
> >> >
> >> >The signal should be good strength as it's coming straight out of
> >the
> >> >wall
> >> >(unity gain distribution amplifier to ensure that). I'll post my
> >> >"dmesg |
> >> >grep cx18" below, but have noted that the version listed (1.5.1) is
> >> >significantly newer than what I had in my old system (1.2.0), which
> >is
> >> >why
> >> >I was experimenting with the Ubuntu 10.0.4 install (I now have 10,
> >11
> >> >and
> >> >12 side-by-side on the new hardware).
> >> >
> >> >[ 6.449510] cx18: Start initialization, version 1.5.1
> >> >[ 6.449542] cx18-0: Initializing card 0
> >> >[ 6.449543] cx18-0: Autodetected Hauppauge card
> >> >[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low)
> >->
> >> >IRQ 17
> >> >[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64
> >> >(was
> >> >32)
> >> >[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
> >> >[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
> >> >[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture
> >> >supported
> >> >[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver
> >#0-0)
> >> >[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64
> >x
> >> >32.00 kB)
> >> >[ 7.073040] DVB: registering new adapter (cx18)
> >> >[ 7.249671] cx18-0: DVB Frontend registered
> >> >[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00
> >kB)
> >> >[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20
> >x
> >> >101.25 kB)
> >> >[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x
> >> >51984
> >> >bytes)
> >> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM
> >audio
> >> >(256
> >> >x 4.00 kB)
> >> >[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
> >> >[ 7.249786] cx18: End initialization
> >> >[ 7.441838] cx18-alsa: module loading...
> >> >[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332
> >> >bytes)
> >> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
> >> >(141200
> >> >bytes)
> >> >[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
> >> >[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382
> >> >bytes)
> >> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw
> >firmware
> >> >(16382 bytes)
> >> >_______________________________________________
> >> >ivtv-users mailing list
> >> >ivtv-users@ivtvdriver.org
> >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
> >>
> >> Hi Robert,
> >>
> >> Start a capture (cat /dev/video0 > foo.mpg ) and then cat
> >/proc/interrupts
> >> . You should see the interrupts handled for the cx18 driver
> >increasing.
> >>
> >> If not, then add a debug=0x1ff to the cx18 module options when
> >loading the
> >> module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and
> >try
> >> another capture. You should get lots of debug in /var/log/messages
> >which
> >> might give insight into the problem.
> >>
> >> And for the record, top-posting is _not_ preferred. But in an era of
> >lame
> >> smartphone email clients it is forgivable. ;)
> >>
> >> Regards,
> >> Andy
> >>
> >>
> >That certainly provided a lot of additional messages, though from what
> >I've
> >read, some may be normal, e.g.:
> >[ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send
> >CX18_CPU_DE_SET_MDL
> >[ 454.868754] cx18-0: warning: failed to be awakened upon RPU
> >acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12 msecs
> >[ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005 args
> >0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000
> >
> >I'm not sure what constitutes a problem. I'd post log output but it's
> >about 650 lines from when I modprobed with debug to when I ended
> >capture.
> >Should I go ahead and send it?
> >
> >-Robert
> >_______________________________________________
> >ivtv-users mailing list
> >ivtv-users@ivtvdriver.org
> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> Hi Robert,
>
> Sending it to the list if you want. If it bounces, you can send it
> directly to me.
>
> From the one message set you culled it seems very likely that interrupts
> from the CX23418 chip are not being processed by the cx18 driver's IRQ irq
> handler.
>
> This is likely a system level issue. What other drivers share the irq
> lines with the cx18 driver? See the output of cat /proc/interrupts.
>
> Regards,
> Andy
>
> From cat /proc/interrupts ...
17: 155 0 0 0 IR-IO-APIC-fasteoi
snd_hda_intel, cx18-0

Looks like the sound driver (motherboard on-board audio)?

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
On Wed, Jun 27, 2012 at 5:07 PM, Robert Rust <rjrbytes@gmail.com> wrote:

> On Wed, Jun 27, 2012 at 5:01 PM, Andy Walls <awalls@md.metrocast.net>wrote:
>
>> Robert Rust <rjrbytes@gmail.com> wrote:
>>
>> >On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls <awalls@md.metrocast.net>
>> >wrote:
>> >
>> >> Robert Rust <rjrbytes@gmail.com> wrote:
>> >>
>> >> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
>> >> >dheitmueller@kernellabs.com> wrote:
>> >> >
>> >> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
>> >> >> <peter.schneider@schneideris.com> wrote:
>> >> >> > Sorry to say but I am not likely much more help here. To me it
>> >> >does not
>> >> >> > look promising as there may be a dead card if you get a signal
>> >> >detected
>> >> >> and
>> >> >> > then no actual image.
>> >> >> >
>> >> >> > Thanks,
>> >> >> > Peter
>> >> >>
>> >> >> There are numerous alternatives to it being a dead card.
>> >> >>
>> >> >> Is the firmware installed? Any errors in dmesg?
>> >> >>
>> >> >> Are you interacting with /dev/video0 or /dev/video1? You might be
>> >> >> trying to read the raw video device, which won't work properly in
>> >> >> mplayer without extra arguments.
>> >> >>
>> >> >> Have you tried catting the /dev/video0 to a file and see if it is
>> >> >> non-zero length?
>> >> >>
>> >> >> Note you should be sure the mythbackend is stopped before doing
>> >any
>> >> >of
>> >> >> this.
>> >> >>
>> >> >> Devin
>> >> >>
>> >> >> Firmware is installed. No errors. I've tried both using mplayer
>> >and
>> >> >dumping to a file. The file dump resulted in a 0 byte file (which
>> >is
>> >> >how I
>> >> >ruled out the MythTV software as the problem). I did stop
>> >mythbackend.
>> >> >I've even gone so far as to replicate this problem on a fairly
>> >> >bare-bones
>> >> >Ubuntu 12.04 server install (which wouldn't have any of the MythTV
>> >> >bits).
>> >> >
>> >> >The signal should be good strength as it's coming straight out of
>> >the
>> >> >wall
>> >> >(unity gain distribution amplifier to ensure that). I'll post my
>> >> >"dmesg |
>> >> >grep cx18" below, but have noted that the version listed (1.5.1) is
>> >> >significantly newer than what I had in my old system (1.2.0), which
>> >is
>> >> >why
>> >> >I was experimenting with the Ubuntu 10.0.4 install (I now have 10,
>> >11
>> >> >and
>> >> >12 side-by-side on the new hardware).
>> >> >
>> >> >[ 6.449510] cx18: Start initialization, version 1.5.1
>> >> >[ 6.449542] cx18-0: Initializing card 0
>> >> >[ 6.449543] cx18-0: Autodetected Hauppauge card
>> >> >[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level, low)
>> >->
>> >> >IRQ 17
>> >> >[ 6.449599] cx18-0: Unreasonably low latency timer, setting to 64
>> >> >(was
>> >> >32)
>> >> >[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
>> >> >[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
>> >> >[ 6.750897] cx18-0: Simultaneous Digital and Analog TV capture
>> >> >supported
>> >> >[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c driver
>> >#0-0)
>> >> >[ 7.073037] cx18-0: Registered device video0 for encoder MPEG (64
>> >x
>> >> >32.00 kB)
>> >> >[ 7.073040] DVB: registering new adapter (cx18)
>> >> >[ 7.249671] cx18-0: DVB Frontend registered
>> >> >[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x 32.00
>> >kB)
>> >> >[ 7.249701] cx18-0: Registered device video32 for encoder YUV (20
>> >x
>> >> >101.25 kB)
>> >> >[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI (20 x
>> >> >51984
>> >> >bytes)
>> >> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM
>> >audio
>> >> >(256
>> >> >x 4.00 kB)
>> >> >[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
>> >> >[ 7.249786] cx18: End initialization
>> >> >[ 7.441838] cx18-alsa: module loading...
>> >> >[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware (158332
>> >> >bytes)
>> >> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
>> >> >(141200
>> >> >bytes)
>> >> >[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
>> >> >[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware (16382
>> >> >bytes)
>> >> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw
>> >firmware
>> >> >(16382 bytes)
>> >> >_______________________________________________
>> >> >ivtv-users mailing list
>> >> >ivtv-users@ivtvdriver.org
>> >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>> >>
>> >> Hi Robert,
>> >>
>> >> Start a capture (cat /dev/video0 > foo.mpg ) and then cat
>> >/proc/interrupts
>> >> . You should see the interrupts handled for the cx18 driver
>> >increasing.
>> >>
>> >> If not, then add a debug=0x1ff to the cx18 module options when
>> >loading the
>> >> module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug) and
>> >try
>> >> another capture. You should get lots of debug in /var/log/messages
>> >which
>> >> might give insight into the problem.
>> >>
>> >> And for the record, top-posting is _not_ preferred. But in an era of
>> >lame
>> >> smartphone email clients it is forgivable. ;)
>> >>
>> >> Regards,
>> >> Andy
>> >>
>> >>
>> >That certainly provided a lot of additional messages, though from what
>> >I've
>> >read, some may be normal, e.g.:
>> >[ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send
>> >CX18_CPU_DE_SET_MDL
>> >[ 454.868754] cx18-0: warning: failed to be awakened upon RPU
>> >acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12 msecs
>> >[ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005 args
>> >0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000
>> >
>> >I'm not sure what constitutes a problem. I'd post log output but it's
>> >about 650 lines from when I modprobed with debug to when I ended
>> >capture.
>> >Should I go ahead and send it?
>> >
>> >-Robert
>> >_______________________________________________
>> >ivtv-users mailing list
>> >ivtv-users@ivtvdriver.org
>> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>
>> Hi Robert,
>>
>> Sending it to the list if you want. If it bounces, you can send it
>> directly to me.
>>
>> From the one message set you culled it seems very likely that interrupts
>> from the CX23418 chip are not being processed by the cx18 driver's IRQ irq
>> handler.
>>
>> This is likely a system level issue. What other drivers share the irq
>> lines with the cx18 driver? See the output of cat /proc/interrupts.
>>
>> Regards,
>> Andy
>>
>> From cat /proc/interrupts ...
> 17: 155 0 0 0 IR-IO-APIC-fasteoi
> snd_hda_intel, cx18-0
>
> Looks like the sound driver (motherboard on-board audio)?
>
> -Robert
>

I've now disabled the motherboard audio and blacklisted the driver. Still
no luck dumping to a file and no updates to the /proc/interrupts line when
doing so:
17: 0 0 0 0 IR-IO-APIC-fasteoi
cx18-0

:(
Re: HVR-1600 analog capture not working? [ In reply to ]
Robert Rust <rjrbytes@gmail.com> wrote:

>On Wed, Jun 27, 2012 at 5:07 PM, Robert Rust <rjrbytes@gmail.com>
>wrote:
>
>> On Wed, Jun 27, 2012 at 5:01 PM, Andy Walls
><awalls@md.metrocast.net>wrote:
>>
>>> Robert Rust <rjrbytes@gmail.com> wrote:
>>>
>>> >On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls
><awalls@md.metrocast.net>
>>> >wrote:
>>> >
>>> >> Robert Rust <rjrbytes@gmail.com> wrote:
>>> >>
>>> >> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
>>> >> >dheitmueller@kernellabs.com> wrote:
>>> >> >
>>> >> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
>>> >> >> <peter.schneider@schneideris.com> wrote:
>>> >> >> > Sorry to say but I am not likely much more help here. To me
>it
>>> >> >does not
>>> >> >> > look promising as there may be a dead card if you get a
>signal
>>> >> >detected
>>> >> >> and
>>> >> >> > then no actual image.
>>> >> >> >
>>> >> >> > Thanks,
>>> >> >> > Peter
>>> >> >>
>>> >> >> There are numerous alternatives to it being a dead card.
>>> >> >>
>>> >> >> Is the firmware installed? Any errors in dmesg?
>>> >> >>
>>> >> >> Are you interacting with /dev/video0 or /dev/video1? You
>might be
>>> >> >> trying to read the raw video device, which won't work properly
>in
>>> >> >> mplayer without extra arguments.
>>> >> >>
>>> >> >> Have you tried catting the /dev/video0 to a file and see if it
>is
>>> >> >> non-zero length?
>>> >> >>
>>> >> >> Note you should be sure the mythbackend is stopped before
>doing
>>> >any
>>> >> >of
>>> >> >> this.
>>> >> >>
>>> >> >> Devin
>>> >> >>
>>> >> >> Firmware is installed. No errors. I've tried both using
>mplayer
>>> >and
>>> >> >dumping to a file. The file dump resulted in a 0 byte file
>(which
>>> >is
>>> >> >how I
>>> >> >ruled out the MythTV software as the problem). I did stop
>>> >mythbackend.
>>> >> >I've even gone so far as to replicate this problem on a fairly
>>> >> >bare-bones
>>> >> >Ubuntu 12.04 server install (which wouldn't have any of the
>MythTV
>>> >> >bits).
>>> >> >
>>> >> >The signal should be good strength as it's coming straight out
>of
>>> >the
>>> >> >wall
>>> >> >(unity gain distribution amplifier to ensure that). I'll post
>my
>>> >> >"dmesg |
>>> >> >grep cx18" below, but have noted that the version listed (1.5.1)
>is
>>> >> >significantly newer than what I had in my old system (1.2.0),
>which
>>> >is
>>> >> >why
>>> >> >I was experimenting with the Ubuntu 10.0.4 install (I now have
>10,
>>> >11
>>> >> >and
>>> >> >12 side-by-side on the new hardware).
>>> >> >
>>> >> >[ 6.449510] cx18: Start initialization, version 1.5.1
>>> >> >[ 6.449542] cx18-0: Initializing card 0
>>> >> >[ 6.449543] cx18-0: Autodetected Hauppauge card
>>> >> >[ 6.449585] cx18 0000:04:01.0: PCI INT A -> GSI 17 (level,
>low)
>>> >->
>>> >> >IRQ 17
>>> >> >[ 6.449599] cx18-0: Unreasonably low latency timer, setting
>to 64
>>> >> >(was
>>> >> >32)
>>> >> >[ 6.461752] cx18-0: cx23418 revision 01010000 (B)
>>> >> >[ 6.750896] cx18-0: Autodetected Hauppauge HVR-1600
>>> >> >[ 6.750897] cx18-0: Simultaneous Digital and Analog TV
>capture
>>> >> >supported
>>> >> >[ 7.025228] cs5345 17-004c: chip found @ 0x98 (cx18 i2c
>driver
>>> >#0-0)
>>> >> >[ 7.073037] cx18-0: Registered device video0 for encoder MPEG
>(64
>>> >x
>>> >> >32.00 kB)
>>> >> >[ 7.073040] DVB: registering new adapter (cx18)
>>> >> >[ 7.249671] cx18-0: DVB Frontend registered
>>> >> >[ 7.249673] cx18-0: Registered DVB adapter0 for TS (32 x
>32.00
>>> >kB)
>>> >> >[ 7.249701] cx18-0: Registered device video32 for encoder YUV
>(20
>>> >x
>>> >> >101.25 kB)
>>> >> >[ 7.249726] cx18-0: Registered device vbi0 for encoder VBI
>(20 x
>>> >> >51984
>>> >> >bytes)
>>> >> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM
>>> >audio
>>> >> >(256
>>> >> >x 4.00 kB)
>>> >> >[ 7.249751] cx18-0: Initialized card: Hauppauge HVR-1600
>>> >> >[ 7.249786] cx18: End initialization
>>> >> >[ 7.441838] cx18-alsa: module loading...
>>> >> >[ 7.946958] cx18-0: loaded v4l-cx23418-cpu.fw firmware
>(158332
>>> >> >bytes)
>>> >> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware
>V00120000
>>> >> >(141200
>>> >> >bytes)
>>> >> >[ 8.363961] cx18-0: FW version: 0.0.74.0 (Release 2007/03/12)
>>> >> >[ 9.786496] cx18-0 843: loaded v4l-cx23418-dig.fw firmware
>(16382
>>> >> >bytes)
>>> >> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw
>>> >firmware
>>> >> >(16382 bytes)
>>> >> >_______________________________________________
>>> >> >ivtv-users mailing list
>>> >> >ivtv-users@ivtvdriver.org
>>> >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>> >>
>>> >> Hi Robert,
>>> >>
>>> >> Start a capture (cat /dev/video0 > foo.mpg ) and then cat
>>> >/proc/interrupts
>>> >> . You should see the interrupts handled for the cx18 driver
>>> >increasing.
>>> >>
>>> >> If not, then add a debug=0x1ff to the cx18 module options when
>>> >loading the
>>> >> module (or via echo 0x1ff > /proc/modules/cx18/parameters/debug)
>and
>>> >try
>>> >> another capture. You should get lots of debug in
>/var/log/messages
>>> >which
>>> >> might give insight into the problem.
>>> >>
>>> >> And for the record, top-posting is _not_ preferred. But in an
>era of
>>> >lame
>>> >> smartphone email clients it is forgivable. ;)
>>> >>
>>> >> Regards,
>>> >> Andy
>>> >>
>>> >>
>>> >That certainly provided a lot of additional messages, though from
>what
>>> >I've
>>> >read, some may be normal, e.g.:
>>> >[ 454.856839] cx18-0: irq: sending interrupt SW1: 8 to send
>>> >CX18_CPU_DE_SET_MDL
>>> >[ 454.868754] cx18-0: warning: failed to be awakened upon RPU
>>> >acknowledgment sending CX18_CPU_DE_SET_MDL; timed out waiting 12
>msecs
>>> >[ 454.868788] cx18-0: api: CX18_CPU_DE_SET_MDL cmd 0x20040005
>args
>>> >0x00000001 0x00dc0cd0 0x00000001 0x00000004 0x00008000
>>> >
>>> >I'm not sure what constitutes a problem. I'd post log output but
>it's
>>> >about 650 lines from when I modprobed with debug to when I ended
>>> >capture.
>>> >Should I go ahead and send it?
>>> >
>>> >-Robert
>>> >_______________________________________________
>>> >ivtv-users mailing list
>>> >ivtv-users@ivtvdriver.org
>>> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>>
>>> Hi Robert,
>>>
>>> Sending it to the list if you want. If it bounces, you can send it
>>> directly to me.
>>>
>>> From the one message set you culled it seems very likely that
>interrupts
>>> from the CX23418 chip are not being processed by the cx18 driver's
>IRQ irq
>>> handler.
>>>
>>> This is likely a system level issue. What other drivers share the
>irq
>>> lines with the cx18 driver? See the output of cat /proc/interrupts.
>>>
>>> Regards,
>>> Andy
>>>
>>> From cat /proc/interrupts ...
>> 17: 155 0 0 0 IR-IO-APIC-fasteoi
>> snd_hda_intel, cx18-0
>>
>> Looks like the sound driver (motherboard on-board audio)?
>>
>> -Robert
>>
>
>I've now disabled the motherboard audio and blacklisted the driver.
>Still
>no luck dumping to a file and no updates to the /proc/interrupts line
>when
>doing so:
> 17: 0 0 0 0 IR-IO-APIC-fasteoi
>cx18-0
>
>:(
>_______________________________________________
>ivtv-users mailing list
>ivtv-users@ivtvdriver.org
>http://ivtvdriver.org/mailman/listinfo/ivtv-users

Ok. That confirms the CX23418 interrupts either aren't happening at all or the kernel is getting them.

Easiest things to check are:

A. that you have the cx23418 apu and cpu firmware files under /lib/firmware (or wherever) and that they are correct (or at least bigger than 0 bytes)

B. Move the hvr1600 to a different pci slot. While you have the case open, remove all your legacy pci cards and blow the dust out of all the slots. Reinstall all the cards and then retest.

C. Move the hvr1600 back to the system in which it was working, and verify that it still works.

Regards,
Andy

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
>

> >I've now disabled the motherboard audio and blacklisted the driver.
> >Still
> >no luck dumping to a file and no updates to the /proc/interrupts line
> >when
> >doing so:
> > 17: 0 0 0 0 IR-IO-APIC-fasteoi
> >cx18-0
> >
> >:(
> >_______________________________________________
> >ivtv-users mailing list
> >ivtv-users@ivtvdriver.org
> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> Ok. That confirms the CX23418 interrupts either aren't happening at all
> or the kernel is getting them.
>
> Easiest things to check are:
>
> A. that you have the cx23418 apu and cpu firmware files under
> /lib/firmware (or wherever) and that they are correct (or at least bigger
> than 0 bytes)
>
> B. Move the hvr1600 to a different pci slot. While you have the case
> open, remove all your legacy pci cards and blow the dust out of all the
> slots. Reinstall all the cards and then retest.
>
> C. Move the hvr1600 back to the system in which it was working, and verify
> that it still works.
>
> Regards,
> Andy
>

A. As far as I know, they are correct. Their md5sum matches that of the
firmware files on my old system (which works ... see C below).

B. Still no dice there. It was the only legacy PCI card in the box and the
system is brand new (no dust yet).

C. Yup ... still works in the old system. Dropped it into the old box and
set up a recording specifying that tuner and it's as happy as a clam.

For what it's worth, I put a PVR-250 card in and am also getting the same
results - 0 bytes in dump file (though obviously it doesn't use the cx18
driver). If it is helpful at all, motherboard is an Intel DH77KC desktop
board with an i5 2400 (no K) CPU and 8GB of RAM.

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
Robert Rust <rjrbytes@gmail.com> wrote:

>>
>
>> >I've now disabled the motherboard audio and blacklisted the driver.
>> >Still
>> >no luck dumping to a file and no updates to the /proc/interrupts
>line
>> >when
>> >doing so:
>> > 17: 0 0 0 0 IR-IO-APIC-fasteoi
>> >cx18-0
>> >
>> >:(
>> >_______________________________________________
>> >ivtv-users mailing list
>> >ivtv-users@ivtvdriver.org
>> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>
>> Ok. That confirms the CX23418 interrupts either aren't happening at
>all
>> or the kernel is getting them.
>>
>> Easiest things to check are:
>>
>> A. that you have the cx23418 apu and cpu firmware files under
>> /lib/firmware (or wherever) and that they are correct (or at least
>bigger
>> than 0 bytes)
>>
>> B. Move the hvr1600 to a different pci slot. While you have the case
>> open, remove all your legacy pci cards and blow the dust out of all
>the
>> slots. Reinstall all the cards and then retest.
>>
>> C. Move the hvr1600 back to the system in which it was working, and
>verify
>> that it still works.
>>
>> Regards,
>> Andy
>>
>
>A. As far as I know, they are correct. Their md5sum matches that of the
>firmware files on my old system (which works ... see C below).
>
>B. Still no dice there. It was the only legacy PCI card in the box and
>the
>system is brand new (no dust yet).
>
>C. Yup ... still works in the old system. Dropped it into the old box
>and
>set up a recording specifying that tuner and it's as happy as a clam.
>
>For what it's worth, I put a PVR-250 card in and am also getting the
>same
>results - 0 bytes in dump file (though obviously it doesn't use the
>cx18
>driver). If it is helpful at all, motherboard is an Intel DH77KC
>desktop
>board with an i5 2400 (no K) CPU and 8GB of RAM.
>
>-Robert
>_______________________________________________
>ivtv-users mailing list
>ivtv-users@ivtvdriver.org
>http://ivtvdriver.org/mailman/listinfo/ivtv-users

Robert,

This is likely a problem with the BIOS' or linux kernel configuration of the PCI bridge chip or interrupt controller in your system.

If you can test the mobo with a Window install to eliminate bad mobo hardware, you should.

You can also muck with BIOS PCI settings and hope to get lucky.

At that point you should probably post your problem to the linux kernel mailing list (or some other linux PCI mailing list), with a subject of "Legacy PCI interrupts not working on Intel DH77KC mobo". Explain that you have two different tuner cards, supported by two different drivers and the kernel is not receiving interrupts for either of them. Provide your kernel version and the output lspci -nnnvvv as root and provide a link to this thread. List members may request the complete output of dmesg or /var/log/messages

Regards,
Andy

_______________________________________________
ivtv-users mailing list
ivtv-users@ivtvdriver.org
http://ivtvdriver.org/mailman/listinfo/ivtv-users
Re: HVR-1600 analog capture not working? [ In reply to ]
On Fri, Jun 29, 2012 at 6:07 AM, Andy Walls <awalls@md.metrocast.net> wrote:

> Robert Rust <rjrbytes@gmail.com> wrote:
>
> >>
> >
> >> >I've now disabled the motherboard audio and blacklisted the driver.
> >> >Still
> >> >no luck dumping to a file and no updates to the /proc/interrupts
> >line
> >> >when
> >> >doing so:
> >> > 17: 0 0 0 0 IR-IO-APIC-fasteoi
> >> >cx18-0
> >> >
> >> >:(
> >> >_______________________________________________
> >> >ivtv-users mailing list
> >> >ivtv-users@ivtvdriver.org
> >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
> >>
> >> Ok. That confirms the CX23418 interrupts either aren't happening at
> >all
> >> or the kernel is getting them.
> >>
> >> Easiest things to check are:
> >>
> >> A. that you have the cx23418 apu and cpu firmware files under
> >> /lib/firmware (or wherever) and that they are correct (or at least
> >bigger
> >> than 0 bytes)
> >>
> >> B. Move the hvr1600 to a different pci slot. While you have the case
> >> open, remove all your legacy pci cards and blow the dust out of all
> >the
> >> slots. Reinstall all the cards and then retest.
> >>
> >> C. Move the hvr1600 back to the system in which it was working, and
> >verify
> >> that it still works.
> >>
> >> Regards,
> >> Andy
> >>
> >
> >A. As far as I know, they are correct. Their md5sum matches that of the
> >firmware files on my old system (which works ... see C below).
> >
> >B. Still no dice there. It was the only legacy PCI card in the box and
> >the
> >system is brand new (no dust yet).
> >
> >C. Yup ... still works in the old system. Dropped it into the old box
> >and
> >set up a recording specifying that tuner and it's as happy as a clam.
> >
> >For what it's worth, I put a PVR-250 card in and am also getting the
> >same
> >results - 0 bytes in dump file (though obviously it doesn't use the
> >cx18
> >driver). If it is helpful at all, motherboard is an Intel DH77KC
> >desktop
> >board with an i5 2400 (no K) CPU and 8GB of RAM.
> >
> >-Robert
> >_______________________________________________
> >ivtv-users mailing list
> >ivtv-users@ivtvdriver.org
> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>
> Robert,
>
> This is likely a problem with the BIOS' or linux kernel configuration of
> the PCI bridge chip or interrupt controller in your system.
>
> If you can test the mobo with a Window install to eliminate bad mobo
> hardware, you should.
>
> You can also muck with BIOS PCI settings and hope to get lucky.
>
> At that point you should probably post your problem to the linux kernel
> mailing list (or some other linux PCI mailing list), with a subject of
> "Legacy PCI interrupts not working on Intel DH77KC mobo". Explain that you
> have two different tuner cards, supported by two different drivers and the
> kernel is not receiving interrupts for either of them. Provide your kernel
> version and the output lspci -nnnvvv as root and provide a link to this
> thread. List members may request the complete output of dmesg or
> /var/log/messages
>
> Regards,
> Andy
>

Thanks for the input! Based your subject suggestion, I found the link
below which may be relevant. I'm not versed enough in ACPI to know what
disabling it does, but I'll give it a shot tonight or this weekend just to
see if it allows the card to work.

http://communities.intel.com/message/156435

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
On Fri, Jun 29, 2012 at 6:23 AM, Robert Rust <rjrbytes@gmail.com> wrote:

> On Fri, Jun 29, 2012 at 6:07 AM, Andy Walls <awalls@md.metrocast.net>wrote:
>
>> Robert Rust <rjrbytes@gmail.com> wrote:
>>
>> >>
>> >
>> >> >I've now disabled the motherboard audio and blacklisted the driver.
>> >> >Still
>> >> >no luck dumping to a file and no updates to the /proc/interrupts
>> >line
>> >> >when
>> >> >doing so:
>> >> > 17: 0 0 0 0 IR-IO-APIC-fasteoi
>> >> >cx18-0
>> >> >
>> >> >:(
>> >> >_______________________________________________
>> >> >ivtv-users mailing list
>> >> >ivtv-users@ivtvdriver.org
>> >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>> >>
>> >> Ok. That confirms the CX23418 interrupts either aren't happening at
>> >all
>> >> or the kernel is getting them.
>> >>
>> >> Easiest things to check are:
>> >>
>> >> A. that you have the cx23418 apu and cpu firmware files under
>> >> /lib/firmware (or wherever) and that they are correct (or at least
>> >bigger
>> >> than 0 bytes)
>> >>
>> >> B. Move the hvr1600 to a different pci slot. While you have the case
>> >> open, remove all your legacy pci cards and blow the dust out of all
>> >the
>> >> slots. Reinstall all the cards and then retest.
>> >>
>> >> C. Move the hvr1600 back to the system in which it was working, and
>> >verify
>> >> that it still works.
>> >>
>> >> Regards,
>> >> Andy
>> >>
>> >
>> >A. As far as I know, they are correct. Their md5sum matches that of the
>> >firmware files on my old system (which works ... see C below).
>> >
>> >B. Still no dice there. It was the only legacy PCI card in the box and
>> >the
>> >system is brand new (no dust yet).
>> >
>> >C. Yup ... still works in the old system. Dropped it into the old box
>> >and
>> >set up a recording specifying that tuner and it's as happy as a clam.
>> >
>> >For what it's worth, I put a PVR-250 card in and am also getting the
>> >same
>> >results - 0 bytes in dump file (though obviously it doesn't use the
>> >cx18
>> >driver). If it is helpful at all, motherboard is an Intel DH77KC
>> >desktop
>> >board with an i5 2400 (no K) CPU and 8GB of RAM.
>> >
>> >-Robert
>> >_______________________________________________
>> >ivtv-users mailing list
>> >ivtv-users@ivtvdriver.org
>> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>
>> Robert,
>>
>> This is likely a problem with the BIOS' or linux kernel configuration of
>> the PCI bridge chip or interrupt controller in your system.
>>
>> If you can test the mobo with a Window install to eliminate bad mobo
>> hardware, you should.
>>
>> You can also muck with BIOS PCI settings and hope to get lucky.
>>
>> At that point you should probably post your problem to the linux kernel
>> mailing list (or some other linux PCI mailing list), with a subject of
>> "Legacy PCI interrupts not working on Intel DH77KC mobo". Explain that you
>> have two different tuner cards, supported by two different drivers and the
>> kernel is not receiving interrupts for either of them. Provide your kernel
>> version and the output lspci -nnnvvv as root and provide a link to this
>> thread. List members may request the complete output of dmesg or
>> /var/log/messages
>>
>> Regards,
>> Andy
>>
>
> Thanks for the input! Based your subject suggestion, I found the link
> below which may be relevant. I'm not versed enough in ACPI to know what
> disabling it does, but I'll give it a shot tonight or this weekend just to
> see if it allows the card to work.
>
> http://communities.intel.com/message/156435
>
> -Robert
>
There also appears to be a BIOS update from a couple weeks ago for me to
try.

-Robert
Re: HVR-1600 analog capture not working? [ In reply to ]
On Fri, Jun 29, 2012 at 6:48 AM, Robert Rust <rjrbytes@gmail.com> wrote:

> On Fri, Jun 29, 2012 at 6:23 AM, Robert Rust <rjrbytes@gmail.com> wrote:
>
>> On Fri, Jun 29, 2012 at 6:07 AM, Andy Walls <awalls@md.metrocast.net>wrote:
>>
>>> Robert Rust <rjrbytes@gmail.com> wrote:
>>>
>>> >>
>>> >
>>> >> >I've now disabled the motherboard audio and blacklisted the driver.
>>> >> >Still
>>> >> >no luck dumping to a file and no updates to the /proc/interrupts
>>> >line
>>> >> >when
>>> >> >doing so:
>>> >> > 17: 0 0 0 0 IR-IO-APIC-fasteoi
>>> >> >cx18-0
>>> >> >
>>> >> >:(
>>> >> >_______________________________________________
>>> >> >ivtv-users mailing list
>>> >> >ivtv-users@ivtvdriver.org
>>> >> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>> >>
>>> >> Ok. That confirms the CX23418 interrupts either aren't happening at
>>> >all
>>> >> or the kernel is getting them.
>>> >>
>>> >> Easiest things to check are:
>>> >>
>>> >> A. that you have the cx23418 apu and cpu firmware files under
>>> >> /lib/firmware (or wherever) and that they are correct (or at least
>>> >bigger
>>> >> than 0 bytes)
>>> >>
>>> >> B. Move the hvr1600 to a different pci slot. While you have the case
>>> >> open, remove all your legacy pci cards and blow the dust out of all
>>> >the
>>> >> slots. Reinstall all the cards and then retest.
>>> >>
>>> >> C. Move the hvr1600 back to the system in which it was working, and
>>> >verify
>>> >> that it still works.
>>> >>
>>> >> Regards,
>>> >> Andy
>>> >>
>>> >
>>> >A. As far as I know, they are correct. Their md5sum matches that of the
>>> >firmware files on my old system (which works ... see C below).
>>> >
>>> >B. Still no dice there. It was the only legacy PCI card in the box and
>>> >the
>>> >system is brand new (no dust yet).
>>> >
>>> >C. Yup ... still works in the old system. Dropped it into the old box
>>> >and
>>> >set up a recording specifying that tuner and it's as happy as a clam.
>>> >
>>> >For what it's worth, I put a PVR-250 card in and am also getting the
>>> >same
>>> >results - 0 bytes in dump file (though obviously it doesn't use the
>>> >cx18
>>> >driver). If it is helpful at all, motherboard is an Intel DH77KC
>>> >desktop
>>> >board with an i5 2400 (no K) CPU and 8GB of RAM.
>>> >
>>> >-Robert
>>> >_______________________________________________
>>> >ivtv-users mailing list
>>> >ivtv-users@ivtvdriver.org
>>> >http://ivtvdriver.org/mailman/listinfo/ivtv-users
>>>
>>> Robert,
>>>
>>> This is likely a problem with the BIOS' or linux kernel configuration of
>>> the PCI bridge chip or interrupt controller in your system.
>>>
>>> If you can test the mobo with a Window install to eliminate bad mobo
>>> hardware, you should.
>>>
>>> You can also muck with BIOS PCI settings and hope to get lucky.
>>>
>>> At that point you should probably post your problem to the linux kernel
>>> mailing list (or some other linux PCI mailing list), with a subject of
>>> "Legacy PCI interrupts not working on Intel DH77KC mobo". Explain that you
>>> have two different tuner cards, supported by two different drivers and the
>>> kernel is not receiving interrupts for either of them. Provide your kernel
>>> version and the output lspci -nnnvvv as root and provide a link to this
>>> thread. List members may request the complete output of dmesg or
>>> /var/log/messages
>>>
>>> Regards,
>>> Andy
>>>
>>
>> Thanks for the input! Based your subject suggestion, I found the link
>> below which may be relevant. I'm not versed enough in ACPI to know what
>> disabling it does, but I'll give it a shot tonight or this weekend just to
>> see if it allows the card to work.
>>
>> http://communities.intel.com/message/156435
>>
>> -Robert
>>
> There also appears to be a BIOS update from a couple weeks ago for me to
> try.
>
> -Robert
>

It looks like problems in the kernel with support for the H77 chipset.
There's recent mention of it on the Linux acpi bugzilla list. Updating
bios didn't help, nor have I found kernel flags that seem to fix this.
I'll continue to dig but it looks like I will probably need to find a
different motherboard if I want this working properly in a timely fashion.
Thanks for the assistance.

-Robert