Multiple Kinects on windows: Occasional misbehaviour

[smokhov]

Overview Description:

Have 3 Kinects. Occasionally, the 3rd one sitting on the USB3 expansion card starts spewing:

libusb: error [windows_transfer_callback] detected I/O error 87: [87] The parameter is incorrect.

It does not happen all the time or right away, but occasionally, it lasts variable amount of time before these start showing up and effectively stalling the pipeline for that Kinect with very low or stopped framerate. Sometimes happens shortly after startup, sometimes it can last 5+ minutes before reaching this condition. It was completely frozen before I started playing with the environment per the troubleshooting page, so now at least it can continue though badly after this error starts. Never can recover a runtime when error happens.

The other two Kinects operate normally sitting on the motherboard busses. Shuffling Kinects across ports/hubs gives the same result for whichever is on the card.

Interestingly, an older version of libfreenec2 (<=0.1 I think) with whatever libusb there was is stable with all three Kinects for extended period of time.

Version, Platform, and Hardware Bug Found:

1. Windows 8.1
2. Environment:

        _putenv("LIBFREENECT2_RGB_TRANSFER_SIZE=1048576");
        _putenv("LIBFREENECT2_RGB_TRANSFERS=3");
        _putenv("LIBFREENECT2_IR_TRANSFERS=4");
        _putenv("LIBFREENECT2_IR_PACKETS=128");

1. libusbK backend
2. At 619bd52
3. VS2015

Maybe related to #605.

[xlz]

Try libusbK backend?

[smokhov]

@xlz -- yes as mentioned in the original report ;) in both cases it is libusbK (I understand #605 used the UsbDk backend, but seems the situation is somehow similar.)

[smokhov]

In the swarm of messages just noticed at the beginning when enumerating. Several of these appear for each Kinect; then then proceeds to run as described.

...
[Info] [Freenect2Impl] found valid Kinect v2 @2:5 with serial 500426442542
[Info] [Freenect2Impl] found 3 devices
[Info] [Freenect2Impl] enumerating devices...
libusb: info [cache_config_descriptors] could not access configuration descrip
r (dummy) for '\\.\USB#VID_045E&PID_02D9#6&14634266&0&4': [31] A device attach
 to the system is not functioning.
libusb: info [cache_config_descriptors] could not access configuration descrip
r (dummy) for '\\.\USB#VID_045E&PID_02D9#6&14634266&0&4': [31] A device attach
 to the system is not functioning.
libusb: info [cache_config_descriptors] could not access configuration descrip
r (dummy) for '\\.\USB#VID_045E&PID_02D9#6&14634266&0&4': [31] A device attach
 to the system is not functioning.
libusb: info [cache_config_descriptors] could not access configuration descrip
r (dummy) for '\\.\USB#VID_045E&PID_02D9#6&8A8A4F3&0&5': [31] A device attache
to the system is not functioning.
libusb: info [cache_config_descriptors] could not access configuration descrip
r (dummy) for '\\.\USB#VID_045E&PID_02D9#6&8A8A4F3&0&5': [31] A device attache
to the system is not functioning.
libusb: info [cache_config_descriptors] could not access configuration descrip
r (dummy) for '\\.\USB#VID_045E&PID_02D9#6&8A8A4F3&0&5': [31] A device attache
to the system is not functioning.
[Info] [Freenect2Impl] 16 usb devices connected
...

[smokhov]

And just got numerous

libusb: error [windows_transfer_callback] detected I/O error 170: [170] The requ
ested resource is in use.

Interestingly an older Processing-based app with libfreenect2, older version, and older libusb works properly and stable with these same 3 Kinects without re-attaching them or rebooting....

[xlz]

I don't see what libfreenect2 can do for this if things already stop working during device enumeration.

Try three instances of Protonect.exe <serial>? This makes sure of threading issues.

You said changes in versions could make it work, so which combinations? Current libfreenect2 with old libusb? Old libfreenect2 with current libfreenect2? How old?

[smokhov]

@xlz

I don't see what libfreenect2 can do for this if things already stop working during device enumeration.

They don't stop, they continue in the way I described, I simply noticed these messages that are usually scrolled away very fast. I think they are output with the libusb debug level 3 and I hoped they'd provide some insight.

I was running actually a multiprocess application, but not Protonect. I will get back to you on the rest probably this weekend.

I was also able to reliably reproduce error 87 by forceably scrolling and not letting go off the terminal output while looking for the messages in the beginning of the output while it was all running. It appears output buffering in the terminal stalls it somehow as well causing he errors.

[hzb12]

Hello @smokhov , I'm zhenbo, Thanks for your help, I have already run the MultiCamTk successfully, and I also noticed these messages, do you have a solution?

[smokhov]

@hzb12 -- a bit late I am back here, but playing with the environment variables at the time helped a bit. I don't have the environment currently to re-test, but I think this is related to the hardware compatibility of the expansion cards. Some work better than others and bus speeds are not the same.