On Tue, 2009-03-10 at 10:57 -0400, Josh Borke wrote: > I have an intermittent problem with my hvr1600 which has been > happening with higher frequency. Whenever I cat the device I receive > only garbage (as reported by the file command). Sometimes when I load > the module with different debug options I can get it to work but > recently that hasn't been working for me either. > > I am using cx18 v1.0.4 and ivtv v1.4.0 > > I have attached the dmesg output after doing: > > modprobe cx18 debug=127 > ivtv-tune -c 3 -d /dev/hvr1600 (I use udev to rename the card to hvr1600) > cat /dev/hvr1600 > /tmp/file.mpg (Ctrl-C after about 2 seconds) > ivtv-tune -c 3 -d /dev/hvr1600 > cat /dev/hvr1600 > /tmp/file2.mpg (Ctrl-C after about 2 seconds) > modprobe -r cx18 > > file /tmp/file.mpg: data > file /tmp/file2.mpg: Dyalog APL component file version 170 .1 > > I'm not sure where to look or what to tweak and would greatly > appreciate any assistance. Let me know if you need more information.
Every time you start capturing, I see this in your logs: cx18-0 file: open encoder PCM audio cx18-0 info: Start encoder stream encoder PCM audio cx18-0 api: CX18_CREATE_TASK cmd 0x40000001 args 0x20020000 cx18-0 api: CX18_CPU_SET_CHANNEL_TYPE cmd 0x20020001 args 0x00000000 0x00000004 [...] cx18-0 api: CX18_CPU_DE_SET_MDL_ACK cmd 0x20040002 args 0x00000000 0x00dc0c80 0x00dc0c88 cx18-0 api: CX18_CPU_CAPTURE_START cmd 0x20020002 args 0x00000000 cx18-0 info: User stopped encoder PCM audio cx18-0 ioctl: close() of encoder PCM audio cx18-0 ioctl: close() of encoder PCM audio cx18-0 info: close stopping capture cx18-0 info: Stop Capture cx18-0 api: CX18_CPU_CAPTURE_STOP cmd 0x20020003 args 0x00000000 cx18-0 api: CX18_CPU_DE_RELEASE_MDL cmd 0x20040006 args 0x00000000 cx18-0 api: CX18_DESTROY_TASK cmd 0x40000002 args 0x00000000 You're opening the wrong device node. You won't get MPEG data from the PCM audio stream. ;) Check your udev rule. I see this device node mapping during initilization: cx18-0: Registered device video1 for encoder MPEG (64 x 32 kB) [...] cx18-0: Registered DVB adapter1 for TS (32 x 32 kB) cx18-0: Registered device video33 for encoder YUV (16 x 128 kB) cx18-0: Registered device vbi1 for encoder VBI (20 x 51984 bytes) cx18-0: Registered device video25 for encoder PCM audio (256 x 4 kB) And I see some userspace "detection" going on: cx18-0 file: open encoder MPEG cx18-0 file: open encoder YUV cx18-0 file: open encoder PCM audio cx18-0: VIDIOC_QUERYCAP driver=cx18, card=Hauppauge HVR-1600, bus=PCI:0000:02:0a.0, version=0x00010004, capabilities=0x01030051 cx18-0 file: open encoder VBI cx18-0: VIDIOC_QUERYCAP driver=cx18, card=Hauppauge HVR-1600, bus=PCI:0000:02:0a.0, version=0x00010004, capabilities=0x01030051 cx18-0: VIDIOC_QUERYCAP driver=cx18, card=Hauppauge HVR-1600, bus=PCI:0000:02:0a.0, version=0x00010004, capabilities=0x01030051 cx18-0: VIDIOC_QUERYCAP driver=cx18, card=Hauppauge HVR-1600, bus=PCI:0000:02:0a.0, version=0x00010004, capabilities=0x01030051 cx18-0 ioctl: close() of encoder YUV cx18-0 ioctl: close() of encoder MPEG cx18-0 ioctl: close() of encoder PCM audio cx18-0 ioctl: close() of encoder VBI But since there is some sort of lag in response to the VIDIOC_QUERYCAP until after the PCM audio device node is open, this may be your problem. Check the logic of the application doing the "detection". > General system info: > Fedora 10 (Mythdora 10.21 with fedora repos enabled and updated against) > v4l-dvb tip as of Feb 18, 2009 You should use the cx18 driver form v4l-dvb from 8 March 2009 or later. My fix for a video scaling bug was just pulled in. The scaling problem is going to annoy you, once your device node detection is working correctly. :) Regards, Andy > uname -a: Linux 2.6.27.19-170.2.35.fc10.x86_64 #1 SMP Mon Feb 23 > 13:00:23 EST 2009 x86_64 x86_64 x86_64 GNU/Linux > > Thanks, > -josh _______________________________________________ ivtv-users mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-users
