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

[Oliver Collyer <ovcollyer@mac.com>]

So today I installed Ubuntu 16.04 on another PC (this one a high spec machine with a Rampage V Extreme motherboard) and I reproduced exactly the same errors and trace.

Rebooting the same PC back into Windows 10 and using the same USB 3.0 port, I had no problems capturing using FFmpeg via DirectShow. I could start and stop the capture repeatedly without any warnings or errors appearing in FFmpeg (built from the same source).

If the hardware is misbehaving, on both these capture devices, then DS must be handling it better than V4L2. Or there is simply an obscure bug in V4L2 which only manifests itself with certain devices.

Would providing ssh access to the machine be of interest to anyone who wants to debug this?

> 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?
> 
> 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.
> --
> 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