none
IR projector does not start after application crashed or debugging cancelled RRS feed

  • Question

  • I have a very annoying issue with the SkeletonStream:

    Since I moved to the 1.0 SDK the skeleton tracking does not work in these two scenarios:

    1. The Kinect application running prior to the new instance crashed without calling KinectSensor.Stop()

    2. The previous instance was stopped using 'Stop Debugging', also causing KinectSensor.Stop() to not be called

    When a new Kinect application starts after 1. or 2. occured, the Kinect-initialization takes a great deal longer (5 seconds or so) and the IR projector is turned off. (You can see that by looking at the Kinect.)

    Do you also have this issue? Is there a workaround for it?

    (I use the 'old' Kinect.)

    greetings,

    ~theCake


    Life is unsure - always eat the dessert first!

    Friday, March 9, 2012 9:11 AM

Answers

  • Okay, I will try the console app version..

    But anyways: This topic should be addressed! The problem can also occur in an end user environment!) Also why doesn't the driver doesn't check whether the Sensor is still active before inverting its status?


    Life is unsure - always eat the dessert first!


    this is an issue in our backlog and we are looking at solutions. I don't follow your last sentence though. The runtime calls the driver to start. At that point, the sensor is active. Without a call to stop, the driver remains in the open state. Without that call, there's no way for the driver to know if it needs to stop unless it polls for runtime activity which leads to a whole other set of circumstances.
    Saturday, March 10, 2012 7:45 AM

All replies

  • unfortunately the driver doesn't know when the runtime has disappeared, so the sensor stays on. You could write a small console app that just calls KinectSensor.Stop() to workaround this. Or unlug/replug. I use a simple app.
    Friday, March 9, 2012 11:25 PM
  • Okay, I will try the console app version..

    But anyways: This topic should be addressed! The problem can also occur in an end user environment!) Also why doesn't the driver doesn't check whether the Sensor is still active before inverting its status?


    Life is unsure - always eat the dessert first!

    Saturday, March 10, 2012 12:05 AM
  • Okay, I will try the console app version..

    But anyways: This topic should be addressed! The problem can also occur in an end user environment!) Also why doesn't the driver doesn't check whether the Sensor is still active before inverting its status?


    Life is unsure - always eat the dessert first!


    this is an issue in our backlog and we are looking at solutions. I don't follow your last sentence though. The runtime calls the driver to start. At that point, the sensor is active. Without a call to stop, the driver remains in the open state. Without that call, there's no way for the driver to know if it needs to stop unless it polls for runtime activity which leads to a whole other set of circumstances.
    Saturday, March 10, 2012 7:45 AM
  • Theirs no magic stop switch an app has to tell the device to stop or it doesnt! But couldn't their be a timeout added todd so that kinect sensor stops ir in the driver if it doesnt receive a response in a certain amount of time depending on the number of the kinect sensor in the collection because each kinect sensor probably adds time onto the intialization/quiting an application? That sounds like the easiest fix that could be made on your end. But other then that theCake I see that todd's reasoning is correct from my dealings with dsf(device simulation framework) which does use kernel level components to create the emulated device.

    Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth. - "Sherlock holmes" "speak softly and carry a big stick" - theodore roosevelt. Fear leads to anger, anger leads to hate, hate leads to suffering - Yoda


    Monday, March 12, 2012 8:37 PM