Hangs after a while on Windows 7

[ronin8600]

I'm having problems with libfreenect2 on Intel 8 Series/C220 Chipset in Windows 7

After a couple of minutes Protonect or my application using libfreenect2 will crash with "subpacket to larger errors" filling the log

Things I've tried

• Update Intel Chipset Drivers (Seemed to make it worse)
• OpenGL, CPU, OpenCL Processors
• Turned off debug logging
• Disabled all USB power management I can find (This had had the greatest affect so far, but still not stable)

On the same machine I have no problems using Linux or Windows 8, so this appears to possibly be an Intel driver problem.

Does anyone have an idea on what may be going on or what I should look at next?

I'm planning to try some different PCI-E Express USB 3 cards to see if I have better luck

[xlz]

How does it crash? If it crashed, do you have a stack trace to find out where it crashed? Maybe you can run a debug build in Visual Studio and find out the crash point.

"Subpacket too large" can appear but should not appear too often. Is Protonect.exe able to continue working if you disable debug output with >NUL?

[ronin8600]

Crash was probably the wrong term to have used since the application doesn't crash with a stack trace

What ends up happening is that libfreenect2 spams the log with "Subpacket too large" and I no longer receive depth packets after that.

[xlz]

The only thing left to look at is disabling console output. Windows console scrolling is extremely slow, but most of the time you don't see it.

[xlz]

Oh,

"Turned off debug logging" if you have done this, there should be no more "subpacket too larger" output at least.

[ronin8600]

Yeah, but still no depth frame packets after a couple of minutes.

I'll report back once I do some more testing with other USB3 PCI-E controllers to see if its a driver issue.

Thanks for the quick replies

[xlz]

Microsoft says https://msdn.microsoft.com/en-us/library/dn782036.aspx

Supported Operating Systems and Architectures
The following operating systems and architectures are supported:
Windows 8 (x64)
Windows 8.1 (x64)
Windows 8 Embedded Standard (x64)
Windows 8.1 Embedded Standard (x64)

Explanation:

Kinect for Windows Team 21 Jul 2014 5:51 PM #
Hello Jade, Kojack, John, Fredano and Win7,

We appreciate your feedback. We would like to support Windows 7 but the USB 3.0 support
is not robust enough. We recommend that you upgrade to Windows 8, as this is the only OS
supported at this time for Kinect for Windows v2.

Thank you.

Perhaps we might find a way for libfreenect2.

[xlz]

OK, one more thing. You can turn on and analyze debug output of libusb with environment variable LIBUSB_DEBUG=3.

[xlz]

@ronin8600 Now I have a Windows machine to test your issue. Are you able to reproduce this issue with Protonect.exe -noviewer? In my case it does not crash with -noviewer. I reproduced it with -noviewer.

I did see the viewer hang, and "Application not responding" message. I don't know if this is what you meant by crash.

Edit: Also, I did not see flooding of "subpacket to larger errors". My crash was libusb hanging, and no data at all was passed to onDataReceived.

[ronin8600]

Sorry for the late response.

Crash was probably the wrong description of my problem. I was seeing a large amount of "subpacket to larger errors" and after that I would not receive any more data unless I restarted.

I've done some preliminary testing with a different USB3 chipset made by VIA and everything seems to be working fine when connecting the kinect to that card. It looks like a problem may be with the Intel driver since the intel chipset works fine on Linux.

VIA Card - Anker® Uspeed USB 3.0 PCI-E Express Card (http://www.amazon.com/gp/product/B005ARQV6U?psc=1&redirect=true&ref_=oh_aui_detailpage_o07_s00)

[xlz]

It seems adjusting transfer pool size mitigates this.

[ronin8600]

How did you adjust the transfer pool size?

What transfer pool size seemed to work for you?

[xlz]

• Change https://github.com/OpenKinect/libfreenect2/blob/master/src/libfreenect2.cpp#L53 PKTS_PER_XFER to 128, NUM_XFERS to 4, and
• Change https://github.com/OpenKinect/libfreenect2/blob/master/src/libfreenect2.cpp#L664 to rgb_transfer_pool_.allocate(3, 2*1024*1024);
• https://github.com/OpenKinect/libfreenect2/blob/master/src/libfreenect2.cpp#L756, submit(3)

My tested setup is Windows7 and NEC uPD720200.

[ronin8600]

Thank you, I will give it a try

[xlz]

Added to https://github.com/OpenKinect/libfreenect2/wiki/Troubleshooting#windows-7-hangs-after-a-while

[ronin8600]

Hi xlz,

Sorry for not posting sooner.

I tested using your recommended changes to mitigate the windows 7 USB issue and everything seems to work as expected.

Thanks again for all of your help.

[ronin8600]

Upgraded to latest and followed your guide under troubleshooting and I encountered the Windows 7 USB3 problem again when the computer was under load (other applications running).

I used your previously recommended values and everything appears to be working fine again. You may want to consider updating windows 7 hang troubleshooting with the following values instead

LIBFREENECT2_IR_PACKETS=128 LIBFREENECT2_IR_TRANSFERS=4 LIBFREENECT2_RGB_TRANSFER_SIZE=2097152 LIBFREENECT2_RGB_TRANSFERS=3

[xlz]

https://github.com/OpenKinect/libfreenect2/blob/master/src/libfreenect2.cpp#L665

I have put into code these defaults, slightly different from your values here. Did the defaults not work?

  ir_pkts_per_xfer = 64;
  ir_num_xfers = 8;
  rgb_xfer_size = 1048576;
  rgb_num_xfers = 3;

[ptmcgrat]

I have a potentially related issue.

I have succeeded in installing libfreenect2 on an XU4 Odroid and can successfully run Protonect and access the data through python bindings.

However, if i leave it running for 24 hours, at some point (can be 1 hour to 11 hours later), it hangs waiting for a frame.

Is this expected? I.e. i need to be setting the timeout values and trying to restart the code from there?

Or does this indicate that there is an issue with one of my settings, potentially causing some aspect of the computer to fall asleep or enter power saving mode.

[xlz]

@ptmcgrat It's probably a bug somewhere. If you can access the hanging program and create a coredump it may be possible to debug it.

[ptmcgrat]

The program hangs on the pylibfreenect waitForNewFrame() command without receiving a new frame. The error reported from the Debug level of the logger is just subpacket to large over and over.

Should i follow the advice above to get more relevant info? "OK, one more thing. You can turn on and analyze debug output of libusb with environment variable LIBUSB_DEBUG=3."

Is there something else i can do to see what is going wrong?