Re: uvcvideo error on second capture from USB device, leading to V4L2_BUF_FLAG_ERROR

[Oliver Collyer <ovcollyer@mac.com>]

> On 5 Sep 2016, at 23:19, Andrey Utkin <andrey_utkin@fastmail.com> wrote:
> 
> On Mon, Sep 05, 2016 at 10:43:49PM +0300, Oliver Collyer wrote:
>> I do not have any knowledge of uvcvideo and the associated classes apart from the studying I’ve done the past day or two, but it seems likely that error -71 and the later setting of V4L2_BUF_FLAG_ERROR are linked. Also, the fact it only happens in captures after the first one suggests something isn’t being cleared down or released properly in uvcvideo/v4l2-core at the end of the first capture.
>> 
>> Let me know what I need to do next to further narrow it down.
> 
> Have tried to reproduce this (with kernel 4.6.0 and fresh build of
> ffmpeg) with uvcvideo-driven laptop webcam, and it doesn't happen to me.
> Also -EPROTO in uvcvideo comes from low-level USB stuff, see
> drivers/media/usb/uvc/uvc_status.c:127:
> 
> 	case -EPROTO:		/* Device is disconnected (reported by some
> 				 * host controller). */
> 
> So it seems like hardware misbehaves. To further clairify situation, I
> have such question: do the devices work in other operation systems on
> the same machine?
> 

Yes, they work perfectly with dshow on Windows on on multiple PCs including this one.

> Reviewing your original email mentioning that two different devices
> reproduce same problem, which is apparently related to disconnection in
> the middle of USB communication, I came to me that the connected device
> may be underpowered. So,
> - try plugging your devices through reliable _active_ USB hub,
> - use the most reliable cables you can get,
> - plug into USB 3.0 port if available - it should provide more power
>   than 1.0 and 2.0.

I will experiment with different ports and report back.

Still, I’m not sure how that suggestion fits with the fact that it always works perfectly after "modprobe -r uvcvideo && modprobe uvcvideo” and only fails again once the capture is stopped and restarted?

Perhaps some kind of “quirk” can be added for these devices that does some extra clearing up/re-initializing at the start of the capture - kind of like *some* of what reloading the module does but only for the specific device.

> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html