elliotwoods / ofxKinectForWindows2

Implementation of Kinect For Windows v2 API (not using KinectCommonBridge)
163 stars 70 forks source link

Depth stream stops working in release mode #61

Open chriship opened 8 years ago

chriship commented 8 years ago

Hi,

This is a fairly obscure issue that I don't really expect to be looked into much but thought i'd put out there just in case.

I have noticed that the depth stream for the Kinect will stop working after a while (sometimes a couple of hours, sometimes a couple of days). This only seems to happen when I have a piece of acrylic placed in front on the camera. If the acrylic is at an angle and spaced 1cm or so in front of the camera it will happen quicker than if the acrylic is flat on the surface of the camera.

The project also needs to be built in release mode for the issue to occur. I presume this is something to do with the answer here: http://stackoverflow.com/questions/186237/program-only-crashes-as-release-build-how-to-debug

When I go into the Kinect Configuration Verifier it confirms that: No depth frames received from Kinect.

I cannot seem to replicate the issue when using the Depth Basics example from the Kinect SDK so am assuming it is within this addon.

EDIT: I should also note that this is on the 0.8.4 branch

EDIT: I should also note that the thickness of the acrylic plays a part in this - the thicker the acrylic, the faster it takes for the depth stream to freeze.

fralken commented 8 years ago

I typical case when Kinect freezes is when a frame is not released after it is acquired. The only code path I can see when this can happen in this addon is when AcquireLatestFrame fails. For example, see BaseImage.cpp.

Just as a quick hack to check if this is the case, can you add a SafeRelease(frame); before the return (line 55), and try again? If you are using initMultiSource you should also add this line in Depth.cpp (line 103) and in Device.cpp. (line 213).

I see that in Depth Basics the Frame is always released, even when AcquireLatestFrame fails, so this can really be the issue.

EDIT: I noticed just now that you're working on the 0.8.4 branch. In this case you should change BaseImage.cpp (line 151).

chriship commented 8 years ago

Thanks for the advice, have added the SafeRelease and will update soon 👍

chriship commented 8 years ago

Ok, adding the SafeRelease(frame); on line 151 didn't work but I do think I have solved it be doing the following:

HRESULT hr = this->reader->AcquireLatestFrame(&frame);
if(SUCEEDED(hr)){
    //acquire frame
    //if(FAILED(this->reader->AcquireLatestFrame(&frame))) {
    //    return; // we often throw here when no new frame is available
    //}

    // --- rest of allocation code here ---
}

SafeRelease(frameDescription);
SafeRelease(frame);

This way safe release is called no matter what. I will close it once the app has been running for a while longer and I can be sure.

fralken commented 8 years ago

Yes, that's basically the same idea: SafeRelease(frame) must always be called after AcquireLatestFrame()

chriship commented 8 years ago

Looks like the fix didn't work :( The Kinect still freezes after some time.

I'll keep messing with the BaseImage class and post any updates here.

fralken commented 8 years ago

Are you sure you are calling SafeRelease(frame) for every kind of frame you are acquiring (e.g. color, depth, ir, body index...) ?

elliotwoods commented 7 years ago

hey all! any progress with this? would be good to hear.

I added the SafeRelease to BaseImage and Device here: https://github.com/elliotwoods/ofxKinectForWindows2/commit/2ef20ac985d9e1774bc6aa4cd3a3c1110bd05f51

i know this isn't a very 'correct' answer at all, but if you're designing something interactive in openFrameworks, it is strongly recommended to restart your app once every 24 hours. You could chase down every long-term running bug and still encounter issues. A common example of where oF fails for long run times (e.g. weeks) is that it often uses float for representing time (which just becomes inaccurate after a few days, often resulting in 'lower frame rate').

In your case you could use a watchdog app (e.g. RestartOnCrash), and just quit your application whenever you detect that the stream is failing.

I hope you find a practical solution :)

chriship commented 7 years ago

Hi Elliot,

In the end I found a different piece of acrylic which didn't freeze the kinect. But none of the suggestions above worked. As I said, it's a pretty obscure situation I guess so I wouldn't lose sleep over it!

Your right about restarting the pc. I was doing this - the problem was that sometimes it would freeze after a couple of hours.