IKinectSensor get_IsAvailable method fails RRS feed

  • Question

  • IKinectSensor get_IsAvailable method continues to fail in the production release.

    On Windows 8.1 x64 with current windows updates
    KinectSDK-v2.0_1409-Setup.exe yet the *actual* installed Kinect20.dll is 2.0.1410.18000

    BOOLEAN bIsAvail = false;
    hr = pKinect2Sensor->get_IsAvailable(&bIsAvail);

    hr returns S_OK
    bIsAvail is always zero regardless of sensor being plugged in or out

    bIsAvail to be true when plugged in.  false when unplugged


    Sunday, October 26, 2014 11:52 AM

All replies

  • To add to this...

    I tried with the Alpha device and Alpha adapter - it didn't work - always returned 0

    I tried with the Alpha device with the production adapter - it didn't work - always returned 0.

    I tried with the Production device with the production adapter - it didn't work - always returned 0.

    However whenever I connected with Kinect Studio with the Device - no file opened in Kinect Studio just the live device, both Alpha and Production devices and adapters worked successfully. The IsAvailable returned x1.

    Hope this helps with this bug.

    Sr. Enterprise Architect | Trainer | Consultant | MCT | MCSD | MCPD | SharePoint TS | MS Virtual TS |Windows 8 App Store Developer | Linux Gentoo Geek | Raspberry Pi Owner | Micro .Net Developer | Kinect For Windows Device Developer |blog:

    Monday, October 27, 2014 7:16 AM
  • You need to wait ~300ms from the time you call Open. There is a delay before the property is set. You can continue to poll or use setup a callback message loop.


    Carmine Sirignano - MSFT

    Monday, October 27, 2014 9:48 PM
  • There seems to be a lack of clarity on the intention and usage of get_IsAvailable

    What was the API designed to do?
    Does it actually do it?
    What are the requirements before and after the use of the API? Nothing is documented in the SDK and your above only hints.
    Does it require a successfull Open() to be called before it?
    Is the 300ms guaranteed? If not what is the lower and upper limit? I now have to manage this.

    This is all rather kludgey. Me having to setup the entire subscribe/unsubscribe/callback chain of code and create a wait timer for 300 ms just to get an answer to a simple question..."is the sensor plugged in and available?


    Monday, October 27, 2014 10:18 PM
  • On my system it was 300ms, test and see what it does for you. If you prefer check the state on in the update loop. To use the SDK and get any data, you must call Open(), see samples for example code.

    What is the scenario you are trying to guard against? How are you using IsAvailable and is the state wrong in the event you are getting frames?

    The api's are designed to work regardless if the sensor is available or not, if there is no sensor, you get no data.

    Carmine Sirignano - MSFT

    Monday, October 27, 2014 11:03 PM
  • My customers are developers; I create extensions for the Cycling74 Max environment. I have dozens on my private beta testing it now. As such, I have no control on the specific computer on which it will be used. Anything that meets Microsoft Kinectv2 requirements...are my requirements. Any timing test I would do is likely invalid due to the lack of hundreds of test machine of various computing power sitting in a test lab like Microsoft has themselves.

    My developers want to know if the sensor is plugged in, powered, and ready to send data aka is the sensor available. This allows them to do intelligent error handling, present UIs guiding end customers to correct sensor connectivity, etc.

    There is a difference between "no data" and "sensor isn't plugged in and ready" could be substantial. The approach of looking for a E_PENDING for 1 second...for 300 still kludgey and might work on some machines...might not on others. It reminds me of the IE3 days when we would create a loop to keep banging on the same IE VBScript API because if you would eventually work.

    I've got every feed of Kinectv2 working except for face. I'm familiar with the workings. What is unclear and undocumented is the working of this get_IsAvailable() API.

    My repro case is at the top.

    Are you suggesting to wait-around for 300ms on your machine and maybe then the API will return a valid result? What do I do for the machines other than yours where it isn't 300ms?

    I'm seeking a reliable API that doesn't depend on me polling it for an unknown amount of time until it works or I assume that maybe it will never work or the result is false.

    If the API needs 300ms (or some other amount of time) to have a valid result, then the API needs to block itself and manage its own delay.


    Tuesday, October 28, 2014 11:18 AM
  • IsAvailable works just you need to wait for the value to get set after you call Open as stated. If you want, add a Sleep(xxx); between open and get_IsAvailable, with the .Net api's you don't have to do that.

    The alternative is to add an event for the callback and listen for that to trigger in your background thread.

    Carmine Sirignano - MSFT

    Tuesday, October 28, 2014 7:03 PM
  • The event callback model will not work for the primary detect if the sensor *is not* plugged in.
    In that scenario, no event callback would fire...because the "result" starts off as false...and it would remain false.

    What is the minimum and maximum values of milliseconds for which I need to wait? What did your testing across multiple machines result in learning? This number is needed **and should be documented** so all developers using the SDK know how long to wait before we *guess* that it isn't plugged in.  :-(


    Tuesday, October 28, 2014 8:46 PM
  • 300ms was what worked for me on my Surface Pro 3, MacBook Pro, i7 Haswell and Sandy Bridge systems. The IsAvailable property will be available to your application after you call Open and ~300ms. The property is set asynchronously.

    Are you saying that this never gets set for you even if you poll for the value? How are you handling the surprise removal when the sensor is disconnected then? You should always be checking the value or setting the callback.

    Carmine Sirignano - MSFT

    Tuesday, October 28, 2014 11:06 PM
  • I made some tests using the sleep: even setting the sleep parameter to 1000 milliseconds sometimes (1 on 10-20 times) the get_IsAvailable fails without disconnecting the kinect from a test to another.

    I can't use it in production and i agree with Dale: if this function needs a sleep it has to be inserted into the sdk not externally!

    Wednesday, October 29, 2014 10:02 AM
  • This is my fear. Thank you @Cag for sharing your failure experience.

    @Carmine, I'm seeking a solution that your test lead will signoff on, that will be documented, and that survives a future Kinectv2 driver/service change. For example, maybe a future driver change now needs 500ms.


    Wednesday, October 29, 2014 10:36 AM
  • If you are waiting to know if the sensor is connected or not, you should also be concerned if the sensor gets disconnected. See the comment on the Kinect API Overview:

    "display a message to the user indicating that the sensor is unavailable. "

    This will require you continually monitoring the value(polling or subscribing to the event). Since the state of the sensor properties happen asynchronously, the official guidance is to use one of the two mechanisms mentioned.

    Can you confirm if you are able to see the state change at any point, or does it always return false? As well, if you already have an application running, is the time the same?

    Carmine Sirignano - MSFT

    Wednesday, October 29, 2014 4:47 PM
  • This code seems to work:

    			while (1)
    				if (isAvaiable == false)
    					OutputDebugString(L"No Kinect Found! Retrying...\n");					

    Infact, if the first time the Kinect hasn't been discovered, the second time it does.

    Anyway i think it's a little dirty, and i push you to find a better solution.

    Thursday, October 30, 2014 7:54 AM
  • Please do remain focused on the troublesome scenario.
    - sensor physically not plugged in
    - app starts
    - ?? App needs to know via API if the sensor is connected ??

    It is this scenario that events don't help (I wrote of that above).

    The only workaround so far is to do some sort of polling and sleep() until you've waited "I hope its long enough" to finally guess that it isn't connected. This is not deterministic and your suggestion of 300ms have proven to be unreliable in real world testing by @Cag.

    Other transitions can be handled by events. Those are not the scenarios I continue to inquire on.


    Thursday, October 30, 2014 11:55 AM