Re: uvcvideo: Dropping payload (out of sync)
On 10.04.2013 08:05, André Weidemann wrote: Hi, I ran into a problem while trying to get a "Microsoft LifeCam Studio(TM)" (045e:0772) to work with uvccapture on a Raspberry PI running Kernel 3.6.11 under Debian Wheezy. I started grabbing a picture with: /usr/bin/uvccapture -x1920 -y1080 -o/media/ramdisk/webcam.jpg -q80 [1] http://ftp.de.debian.org/debian/pool/main/u/uvccapture/uvccapture_0.5.orig.tar.gz [2] http://ftp.de.debian.org/debian/pool/main/u/uvccapture/uvccapture_0.5-2.debian.tar.gz Grabbing a picture takes between 20 seconds and 1-2 minutes. Unfortuantely the captured image is heavily distorted. For anyone who may also run into this problem here is a solution... It seems the problem is hardware related to the Raspberry Pi. The solution can be found here: https://github.com/raspberrypi/linux/issues/238 https://github.com/P33M/linux André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
uvcvideo: Dropping payload (out of sync)
Hi, I ran into a problem while trying to get a "Microsoft LifeCam Studio(TM)" (045e:0772) to work with uvccapture on a Raspberry PI running Kernel 3.6.11 under Debian Wheezy. I started grabbing a picture with: /usr/bin/uvccapture -x1920 -y1080 -o/media/ramdisk/webcam.jpg -q80 [1] http://ftp.de.debian.org/debian/pool/main/u/uvccapture/uvccapture_0.5.orig.tar.gz [2] http://ftp.de.debian.org/debian/pool/main/u/uvccapture/uvccapture_0.5-2.debian.tar.gz Grabbing a picture takes between 20 seconds and 1-2 minutes. Unfortuantely the captured image is heavily distorted. Doing a stack trace I see that it always hangs on: ioctl(3, VIDIOC_STREAMON, 0xbe8f15e4) = 0 ioctl(3, VIDIOC_DQBUF So I did an: echo 0x > /sys/module/uvcvideo/parameters/trace This resulted in a rather lengthy kernel log starting like this: Apr 10 07:08:11 raspberrypi kernel: [ 5262.503209] uvcvideo: uvc_v4l2_ioctl(VIDIOC_G_CTRL) Apr 10 07:08:11 raspberrypi kernel: [ 5262.509395] uvcvideo: uvc_v4l2_ioctl(VIDIOC_QUERYCTRL) Apr 10 07:08:11 raspberrypi kernel: [ 5262.509466] uvcvideo: Control 0x00980913 not found. Apr 10 07:08:11 raspberrypi kernel: [ 5262.519683] uvcvideo: uvc_v4l2_ioctl(VIDIOC_STREAMON) Apr 10 07:08:11 raspberrypi kernel: [ 5262.524446] uvcvideo: Device requested 3072 B/frame bandwidth. Apr 10 07:08:11 raspberrypi kernel: [ 5262.524481] uvcvideo: Selecting alternate setting 24 (3072 B/frame bandwidth). Apr 10 07:08:11 raspberrypi kernel: [ 5262.534925] uvcvideo: Allocated 5 URB buffers of 32x3072 bytes each. Apr 10 07:08:11 raspberrypi kernel: [ 5262.540632] uvcvideo: uvc_v4l2_ioctl(VIDIOC_DQBUF) Apr 10 07:08:12 raspberrypi kernel: [ 5263.014155] uvcvideo: USB isochronous frame lost (-63). Apr 10 07:08:12 raspberrypi kernel: [ 5263.019468] uvcvideo: USB isochronous frame lost (-63). Apr 10 07:08:12 raspberrypi kernel: [ 5263.024473] uvcvideo: USB isochronous frame lost (-63). Apr 10 07:08:12 raspberrypi kernel: [ 5263.068612] uvcvideo: USB isochronous frame lost (-63). Apr 10 07:08:12 raspberrypi kernel: [ 5263.078582] uvcvideo: USB isochronous frame lost (-63). Apr 10 07:08:12 raspberrypi kernel: [ 5263.327576] uvcvideo: USB isochronous frame lost (-63). Apr 10 07:08:12 raspberrypi kernel: [ 5263.366721] uvcvideo: Frame complete (overflow). Apr 10 07:08:12 raspberrypi kernel: [ 5263.366759] uvcvideo: Dropping payload (out of sync). It continued to show over 1Mio lines in 5 minutes with: Apr 10 07:08:12 raspberrypi kernel: [ 5263.371102] uvcvideo: Dropping payload (out of sync). intermitted by a few: Apr 10 07:08:12 raspberrypi kernel: [ 5263.388864] uvcvideo: USB isochronous frame lost (-63). After enabling the trace uvccapture was not able to garb an image at all. I had to kill the process. I am at loss here... The whole setup worked flawlessly on my Laptop with Debian Wheezy and kernel 3.2 on an Intel Chipset. I did a few more tests lowering the capture resolution which seemed to work a lot better. Up to 800x600 the images were captured almost instantly, but they were still distorted. At the resolution of 640x480 the images were finally clear. But since the camera supports 1920x1080, I would also like to be able to capture at this resolution... Any help is greatly appreciated. Thanks in advance. André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pctv452e
On 04.07.2012 18:22, Antti Palosaari wrote: On 07/04/2012 07:04 PM, Steve Hill wrote: >> Ps. Steve, could you please give me full version of kernel which >> works with pctv452e? I think it was 2.6.37-1-kirkwood from Debian which I was using (this is an ARM system). > As the new DVB-USB fixes many bugs I ask you to test it. I converted > pctv452e driver for you: > > http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/pctv452e > > Only PCTV device supported currently, not TechnoTrend at that time. Can I ask why it only works on the PCTV devices? I was under the impression that the TechnoTrend hardware was identical? If you are able to provide any pointers as to where the TechnoTrend support is broken (or what debugging I should be turning on to figure out where it is broken) then that would be helpful. I don't have hardware, no PCTV neither TechnoTrend. I just converted PCTV as Marx seems to have such device and he was blaming. Code wasn't 100% similar, for example TechnoTrend has CI PCTV doesn't. It should not fix problems but it could since I fixed some nasty bugs. Lets wait test report first and make decision what to do after that. The pctv452e and TT-connect S2-3600 are identical in hardware. Only USB IDs and remote control codes differ between the two. The Pinnacle box has its own remote. The TT-connect uses the same RC as the TT-budget series. The TT-connect S2-3650-CI has an additional CI slot. André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pctv452e: hm.. tidy bogus code up
Hi Mauro, On 30.09.2011 22:58, Igor M. Liplianin wrote: Currently, usb_register calls two times with cloned structures, but for different driver names. Let's remove it. It looks like the comments and the patch under http://patchwork.linuxtv.org/patch/8042/ got mixed up. Regards, André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pctv452e: hm.. tidy bogus code up
On 03.10.2011 14:30, André Weidemann wrote: Hi Igor, On 30.09.2011 22:58, Igor M. Liplianin wrote: Currently, usb_register calls two times with cloned structures, but for different driver names. Let's remove it. Signed-off-by: Igor M. Liplianin Well spotted... The cloned struct should have been removed a long time go. The final version of patch I submitted for the tt-connect S2-3600, did not contain it anymore: http://www.linuxtv.org/pipermail/linux-dvb/2008-March/024233.html Acked-by: André Weideamm This should read: Acked-by: André Weidemann ;-) Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] pctv452e: hm.. tidy bogus code up
Hi Igor, On 30.09.2011 22:58, Igor M. Liplianin wrote: Currently, usb_register calls two times with cloned structures, but for different driver names. Let's remove it. Signed-off-by: Igor M. Liplianin Well spotted... The cloned struct should have been removed a long time go. The final version of patch I submitted for the tt-connect S2-3600, did not contain it anymore: http://www.linuxtv.org/pipermail/linux-dvb/2008-March/024233.html Acked-by: André Weideamm Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Remote control TechnoTrend TT-connect S2-3650 CI
Hi Jochen, On 19.03.2011 19:40, Jochen Reinwand wrote: I'm using a TechnoTrend TT-connect S2-3650 CI. The S2API support is great! I do not have any problems watching DVB-S and DVB-S2 content. Tuning is quite fast! It's working much better than my Hauppauge WinTV Nova-TD, but that's a different story... The only severe problem I have with the TechnoTrend is related to the remote control. Around 30% of the key presses produce two key events. It's not related to any lirc or X11 configuration issue. I verified it using the tool input-events on the device. There are really two separate events coming from the device. Is this due to a hardware problem, or is it a driver issue? My C and Kernel knowledge is not really the best. But there is some code in dvb-usb-remote.c that seems to be related to key repeats. Are the dvb remote input devices doing something special here? I'm also not able to modify behaviour of the device via "xset r rate" when using it as X11 input device. It's only affecting the real keyboard that is also attached. I don't think that this is a hardware problem. I think it is related to the driver. When I added support for the S2-3650CI to Dominik Kuhlen's code for the PC-TV452e, I used the RC-code function "pctv452e_rc_query" for the S2-3650CI. I ran into this problem back then and thought that setting .rc_interval to 500 would "fix" the problem good enough. Since I never used the supplied remote with my box, I never looked into the problem again. Unfortunately I do not know how to fix this problem. If anyone has some insights on reading remote control inputs, please take a look here and see if you can fix the problem: http://mercurial.intuxication.org/hg/s2-liplianin/file/7e47ba1d4ae8/linux/drivers/media/dvb/dvb-usb/pctv452e.c#l1355 The remote is the same as the one shipped with the TT-S1500. So the code for reading the remote input should already exist. Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] faster DVB-S lock with cards using stb0899 demod
Hello Mauro, On 19.09.2010 11:46, SE wrote: hi list v4l-dvb still lacks fast and reliable dvb-s lock for stb08899 chipsets. This problem was adressed by Alex Betis two years ago [1]+[2]resulting in a patch [3] that made its way into s2-liplianin, not v4l-dvb. With minor adjustments by me this patch now offers reliable dvb-s/dvb-s2 lock for v4l-dvb, most of them will lock in less than a second. Without the patch many QPSK channels won't lock at all or within a 5-20 second delay. Can you please comment on this patch and tell us if you are considering this patch for integration into the v4l git tree? Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hi Hermann, On 30.04.2010 02:31, hermann pitton wrote: Hi, Am Mittwoch, den 28.04.2010, 17:13 +0400 schrieb Manu Abraham: On Wed, Apr 28, 2010 at 12:33 PM, Guy Martin wrote: On Wed, 28 Apr 2010 09:45:39 +0200 André Weidemann wrote: I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. I'm currently running two of these cards in the same box with this patch. Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because sometimes diseqc wasn't working fine and that seemed to solve the problem. I would advise to not do this: since disabling current limiting etc will cause a large problem in the case of a short circuit thereby no protection to the hardware. In such an event, it could probably damage the tracks carrying power on the card as well as the tracks on the motherboard, and in some cases the gold finches themselves and or the PCI connector. Generally, there are only a few devices capable of sourcing> 0.5A, So I wonder Regards, Manu for the few devices I do have, you seem to be for sure right. All the Creatix stuff drawing up to 900mA on a potentially dual isl6405 has direct voltage from the PSU over an extra floppy connector. Max. 500mA should be sufficient with a DiSEqC 1.2 compliant rotor. Nothing else should come above that limit. I wonder, if someone close in reading specs just now, can tell if 900mA can be sufficient for two rotors ;) Andre, BTW, assuming you still have a CTX944 (md8800 Quad), can you measure if the 16be:0008 device really does switch between 13 and 18V. You seem to mistake me for someone else. I do not have a CTX944 and never had. Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hello Guy, On 28.04.2010 10:33, Guy Martin wrote: On Wed, 28 Apr 2010 09:45:39 +0200 André Weidemann wrote: I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. I'm currently running two of these cards in the same box with this patch. Actually, later on I've even set curlim = SEC_CURRENT_LIM_OFF because sometimes diseqc wasn't working fine and that seemed to solve the problem. I used to have skystar2 cards before and I did not run into those issues. Diseqc just worked fine. For reference each tt s2 is plugged to a diseqc switch with 4 output, each output connected to a quad lnb. How come there is such a high current drain to drive the switch plus the LNBs? From what I understand, the switch should only power one LNB at a time. Usually the switch plus the LNB should not drain more than 300-400mA, or am I wrong here? Is there another way to solve this ? Maybe add a module parameter for people who want to override the default ? I think this could be done. Nevertheless, the card would still operate outside its specification. Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] TT S2-1600 allow more current for diseqc
Hello Guy, On 11.04.2010 23:18, Guy Martin wrote: Hi linux-media, The following patch increases the current limit for the isl6423 chip on the TT S2-1600 card. This allows DiSEqC to work with more complex and current demanding configurations. Signed-off-by: Guy Martin I am sorry for the late reply. I advise not to pull this change into the kernel sources. The card has only been testet with the a maximum current of 515mA. Anything above is outside the specification for this card. Kind Regards André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Technotrend TT-Connect S-2400
Hi David, On 24.08.2009 19:17, David wrote: still broken as of 2.6.30. The 2.6.31rc should have the fix, and I have a patch for 2.6.30 if you want it. Could please post a link to this patch? I think that a few people on this list, including me, are interested in a solution. Regards. André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: TT-Connect S2 -3650 CI and a Pinnacle PCTV Dual Sat Pro PCI 4000I
Hi Chris, Christian Heidingsfelder [Heidingsfelder + Partner] wrote: > It seems i own the two not working DVB-S Devices on linux. > Its a TT-Connect S2 -3650 CI and a Pinnacle PCTV Dual Sat Pro PCI 4000I. > Is there any chance to get one of them working. I use Gentoo with the 2.6.29- > gentoo-r5 kernel. a driver for the "Pinnacle PCTV Sat HDTV Pro USB (452e)" was written by Dominik Kuhlen at the beginning of last year. This Pinnacle device is based on the same hardware as the TechnoTrend S2-3600. From what I know Michael H. Schimek has contributed the S2-3650 code and CI handling for the box(anyone, please correct me if I am wrong). Some interim state of drivers for above mentioned devices is currently included in Igor M. Liplianin's repository at http://mercurial.intuxication.org/hg/s2-liplianin/ The linuxtv.org wiki lists a patch under http://www.linuxtv.org/wiki/index.php/TechnoTrend_TT-connect_S2-3650_CI#S2API to be applied, but it fails on some chunks... I'd say your best chance is to start asking the people who wrote the drivers to create a diff against http://linuxtv.org/hg/v4l-dvb that will eventually go into the kernel. As for the "Pinnacle PCTV Dual Sat Pro PCI 4000I"... All I know is that the wiki at http://www.linuxtv.org/wiki/index.php/Pinnacle_PCTV_Dual_Sat_Pro_PCI_4000I lists this device as not supported. Regards. André -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
