C# - SenseManager.StreamFrames(false) is not stopped by SenseManager.Close()

[Pol_P_]

Hi, 

I observed that when I use StreamFrames with a false flag my programs get stuck when I try to stop streaming frames.

According to the documentation StreamFrames method in SenseManager takes a boolean; true for blocking and false for non-blocking.

I am starting my stream like this:

_senseManager.StreamFrames(false);

and to stop it I call:

_senseManager.Close();
_senseManager.Dispose()

This hangs the program when the Close method is called.

However, if I create a new Thread and I call StreamFrames with a true flag everything works fine when I call Close and Dispose.

Something like this works fine:

Task.Factory.StartNew(() => { _senseManager.StreamFrames(true); });

Is this normal? Am I doing something wrong? I would like to call the non-blocking version of StreamFrames but also be able to Close it.

Thanks,

[samontab]

This video may be of help. It explains how to access the raw frames in both modes:

https://www.youtube.com/watch?v=wIkIdjN6Oyw

[Pol_P_]

As I understand, my approach is exactly the same as the one proposed in the video.

The only difference I can see is that the video is using C++ instead of C#. This shouldn't make a difference however...

Thanks,

[samontab]

Pol P. wrote:

As I understand, my approach is exactly the same as the one proposed in the video.

The only difference I can see is that the video is using C++ instead of C#. This shouldn't make a difference however...

Thanks,

Double check the function names though. I remember there were a bit different in different languages. Something like Close in C++ vs CloseDown in C#, or something similar. Or maybe they changed that now.

[Pol_P_]

I just looked up the documentation and the function you have to call is called Close (same as in C++).

Here:

https://software.intel.com/sites/landingpage/realsense/camera-sdk/v1.1/documentation/html/streamframes_pxcsensemanager.html

Thanks,

[samontab]

OK. If you did everything right there might be a bug in the C# implementation...

I guess Intel guys would need to have a sample code to check for this.