LIBUSB_TRANSFER_STALL errno: 4 about uvcc HOT 9 OPEN

Hello @joelpurra and thanks a lot for your answer.

• I'm targetting ELP High Speed Cameras, vid: 1443, pid: 37424
• uvcc 2.0.4, npx 7.5.6, node.js 10.16.2

The camera is seen by uvcc devices, but I do not succeed with ranges, export or other commands as if my device selection was not good.

from uvcc.

@siteswapjuggler: it can be an incompatible/problematic camera or some bug in uvcc (or the upstream uvc-control fork). Anyhow, need more details.

• Which camera (vendor/product ids) are you targeting?
• Which version of uvcc?

from uvcc.

@siteswapjuggler: it does seem that the ELP-USBFHD01M camera series is UVC compatible, confirmed by this blog entry from 2015. Unsure if they all have VID 0x05A3, PID 0x9230, but it looks like it's mostly the lens/housing that changes.

Others had problems with LIBUSB_TRANSFER_STALL in uvcc (#3, #4, makenai/node-uvc-control#52). This was fixed in makenai/node-uvc-control#16 and later incorporated in uvcc v2.0.0 by having more dynamic detection of the camera's controls. At least I thought it was fixed.

Without this particular camera, I can't do much. Since you have the camera available, could you debug it? If not, perhaps using another UVC control software is better. Or ask @ECMAScript3, since they fixed a similar bug before but didn't publish a patch.

from uvcc.

Hi, I have the same error with an HD Pro C920 camera.

I get this error for all the following controls:

Error while updating absolute_exposure_time : [Error: LIBUSB_TRANSFER_STALL] { errno: 4 }
Error while updating absolute_focus : [Error: LIBUSB_TRANSFER_STALL] { errno: 4 }
Error while updating white_balance_temperature : [Error: LIBUSB_TRANSFER_STALL] { errno: 4 }

The strange thing is I can get the current values of this controls, it's not working only when trying to set the value.

I'm posting here, but the bug comes from you're fork (i'm using it directly, not through uvcc).

from uvcc.

@EmrysMyrddin: the error code may be the same, but your issue is different from @siteswapjuggler's issue.

The particular controls you list are presumably "locked" from user modification, because they are in automatic mode. This means that the camera sets the control value, which may vary by light conditions etcetera. Turn off the corresponding automatic mode control(s) first. In a graphical user interface these controls would perhaps be greyed out and the mode toggled by a checkbox. This is unfortunately not very well documented in uvc-control nor uvcc.

The upstream uvc-control v1 didn't implement the full UVC standard, so uvcc doesn't know about whether or not a control is in automatic mode. The later uvc-control v2 implements some additional control functionality, such as checking for the default control values, which may be useful also in uvcc. Work was never finished upstream though, and I have no plans to significantly improve my fork.

from uvcc.

Your right, it was the problem :-) Do you know any way to detect this and avoid this errors ? Or the protocol doesn't allow this ?

from uvcc.

@EmrysMyrddin: the UVC standard allows reading the "automatic mode" state for each control. The uvc-control v2 implementation has getInfo(id) which returns a property disabled. Don't recall if I've used/tested it myself in this implementation though; as mentioned, uvcc does not use it at the moment.

Other UVC library/wrapper may also implement automatic mode state checking. Alternatively, with low-level USB communications open you can send GET_INFO requests to the webcam and check the bits for each control; see the UVC device class specification for details.

• https://www.usb.org/documents?search=uvc
• Some comments on USB and UVC libraries for Node.js development

For follow-up questions to your library usage, please open a new issue in uvc-control.

from uvcc.

@siteswapjuggler: tested a couple of cameras (but in an unstructured approach) and found some hints as to why some (most?) are not working with uvcc.

Here's an explanation regarding UVC control transfers from an experienced USB developer working on WebUSB. The answer is with regards to WebUSB usage, but it seems to apply generally (at least in 2017).

• https://stackoverflow.com/a/44974122

Based on the output from lsusb -v above I can see that this device has a single function comprised of two USB interfaces. The Interface Association Descriptor (IAD) signals to the host operating system that these two interfaces are related and operating systems like Windows will treat them as a single interface for the purposes of driver binding.

My guess is that on Linux and macOS you are able to communicate with the EP 1 IN endpoint because only interface 1 is claimed by the USB video class (UVC) driver. On Windows, since it considers both interfaces a single entity "function 0", you are unable to claim interface 0 because interface 1 is already claimed as part of function 0.

Am not familiar enough with USB to "see" this in the lsusb output, but it coincides with my experience trying to claim interfaces on some cameras. So it may come down to hardware implementation of the USB functions/interfaces, how the on-chip software presents them to the USB host, and how the operating system (and even different versions) treats them.

While uvcc control transfers target the device, which works for some cameras, it might be possible to support additional cameras/operating systems by targeting endpoints as a fallback. (Or implement operating system specific control transfers, not based on libusb but system libraries.)

• joelpurra/node-uvc#1 (comment)
• joelpurra/node-uvc#2 (comment)
• joelpurra/node-uvc-control@13f31e5
• https://github.com/joelpurra/uvcc#compatible-cameras
• https://github.com/joelpurra/uvcc/tree/v6.0.0/examples
• https://github.com/libuvc/libuvc/tree/v0.0.6/cameras
• https://github.com/libuvc/libuvc/blob/v0.0.6/cameras/logitech_hd_pro_920.txt

from uvcc.

Thanks a lot @joelpurra I'll have a look as soon as possible. To be honnest I did not pursue my project using this command that's why I did not give more news recently.

Thanks a lot for your time and your latest answer, really hope that someone will find this usefull and maybe solve the mystery at one point.

from uvcc.