On Wed, Jun 27, 2012 at 4:05 PM, Andy Walls <email@example.com> wrote: > Robert Rust <firstname.lastname@example.org> wrote:
> >On Wed, Jun 27, 2012 at 1:38 PM, Devin Heitmueller <
> >email@example.com> wrote:
> >> On Wed, Jun 27, 2012 at 2:27 PM, Peter Schneider
> >> <firstname.lastname@example.org> 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
> >> 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
> >> 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
> >Ubuntu 12.04 server install (which wouldn't have any of the MythTV
> >The signal should be good strength as it's coming straight out of the
> >(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
> >I was experimenting with the Ubuntu 10.0.4 install (I now have 10, 11
> >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
> >[ 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
> >[ 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
> >[ 7.249749] cx18-0: Registered device video24 for encoder PCM audio
> >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
> >[ 8.353145] cx18-0: loaded v4l-cx23418-apu.fw firmware V00120000
> >[ 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
> >[ 9.845990] cx18-0 843: verified load of v4l-cx23418-dig.fw firmware
> >(16382 bytes)
> >ivtv-users mailing list
> 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. ;)
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
[ 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?