Kinect blocks on events (osx)

[fernLightning]

Occurs on shutdown, freenect_process_events(), freenect_stop_depth(), freenect_stop_video(), or on shutdown if had iso errors during init....

Current solution so far (for osx), modified usb_libusb10.c

• replaced all instances of "libusb_handle_events(..)", with "struct timeval tv = {.tv_sec=1, .tv_usec=0}; libusb_handle_events_timeout(..)" to make things timeout faster.
  • made fnusb_start_iso() do a "strm->dead_xfers++;" when it "Failed to submit isochronous transfer" - to ensure shutdown waits on the correct number of events.

[zarvox]

Yes, we do need to add some proper handling of transfers that come back with some libusb error. Rather than accumulate a pile of workarounds, I'd like to rework the transfers to correctly handle the differences between failed, cancelled, and active transfers, at which point I'd expect this to all work properly.

And you're not alone: issue #227

[fernLightning]

Still locks up on device disconnect. The only solution I've found is to provide means to escape the while loop after a timeout. I'm unsure of the side effects of this, but it is working reliably for me.

int fnusb_stop_iso(fnusb_dev _dev, fnusb_isoc_stream *strm) { ... struct timeval start; gettimeofday(&start, NULL); while (strm->dead_xfers < strm->num_xfers) { struct timeval tv = {.tv_sec=1, .tv_usec=0}; // dont block forever, wait at most 1sec libusb_handle_events_timeout(ctx->usb.ctx, &tv); gettimeofday(&tv, NULL); long msecs = (tv.tv_sec - start.tv_sec)_1000; msecs += (tv.tv_usec - start.tv_usec)/1000; if(msecs > 4000) { FN_WARNING("Stopping - giving up after %ldms\n", msecs); break; } } ... }

[zarvox]

Hmm, so we cancel the transfers, but they never come back as dead? At first glance, that sounds like a libusb bug - we should be getting completed transfers with LIBUSB_TRANSFER_CANCELLED or LIBUSB_TRANSFER_NO_DEVICE.

I'll try to reproduce this - you say this happens to the demos on OSX when you unplug the Kinect?

[fernLightning]

It sometimes happens on disconnect, not always. It happens 1 out of 10 times here in the office with one kinect, but seems to happen far more often on site (where we have three kinects on the one machine).

I've not tried the Demos recently.

[zarvox]

The latest updates in unstable plus the one that adds freenect_process_events_timeout() should hopefully clear up the issues you noted.

In addition, we now return -1 from freenect_process_events if any of the underlying devices in the specified context have disappeared. The library knows which device vanished, but we're still trying to figure out a reasonably clean way to pass that up to the client.