jit.freenect.grab crash

    Feb 19 2013 | 9:02 pm
    I'm failing now at doing something I've done multiple times before, and I'm not entirely sure what's wrong.
    Using a Mac Mini running 6.0.8 and 10.8.2 to get input via jit.freenect.grab from a Kinect. When the Kinect is plugged in, sending an open message is resulting in a crash. Switching machines to a mid-2011 MBP has the same result. So does switching USB ports and switching Kinects to a model bought on the same day. The error is always the same. Downgrading to the RC4 of jit.freenect.grab does not change anything. Synapse still works, as does Dale Phurrough's sensational Mac port of jit.openni, but I am bound by two client strictures: we must use a mac, and we have to use two kinects to make this work (it's a long lane that's being tracked).
    Did Microsoft go and alter the Kinect hardware without talking to anyone?
    Has anyone had a similar experience? It's especially galling because I did the exact same thing last month with no problems, but with 1 y.o. Kinect models....
    This is the crashlog, which is the same on EVERY computer I use with these Kinects:
    Process: Max [470] Path: /Applications/Max6/Max.app/Contents/MacOS/Max Identifier: com.cycling74.Max Version: 6.0.8 [6f52750] (6.0.8) Code Type: X86 (Native) Parent Process: launchd [189] User ID: 501
    Date/Time: 2013-02-19 14:51:56.794 -0500 OS Version: Mac OS X 10.8.2 (12C60) Report Version: 10
    Interval Since Last Report: 246710 sec Crashes Since Last Report: 8 Per-App Interval Since Last Report: 67167 sec Per-App Crashes Since Last Report: 5 Anonymous UUID: 75078D2B-9982-F7BD-1A99-18D89461DA9C
    Crashed Thread: 0 Dispatch queue: com.apple.main-thread
    Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000005c
    VM Regions Near 0x5c: --> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Applications/Max6/Max.app/Contents/MacOS/Max __TEXT 0000000000001000-0000000000676000 [ 6612K] rwx/rwx SM=COW /Applications/Max6/Max.app/Contents/MacOS/Max
    Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.jmp.jit.freenect.grab 0x06e803ca freenect_set_depth_callback + 9 1 com.jmp.jit.freenect.grab 0x06e787fc jit_freenect_grab_open + 517 2 com.cycling74.Max 0x000b8aa5 object_method + 963 3 com.cycling74.MaxAPI 0x04dc533b object_method + 139 4 com.cycling74.JitterAPI 0x0e9ff474 jit_object_method + 118 5 com.cycling74.JitterAPI 0x0ea1d517 max_jit_gimme_method + 69 6 com.cycling74.Max 0x000261cc typedmess_fun + 1050 7 com.cycling74.Max 0x0006c41c outlet_anything + 846 8 com.cycling74.Max 0x000261cc typedmess_fun + 1050 9 com.cycling74.Max 0x00026581 typedmess + 72 10 com.cycling74.Max 0x00027577 aeval + 1288 11 com.cycling74.Max 0x000102d9 atombuf_eval + 145 12 com.cycling74.MaxAPI 0x04dc3594 atombuf_eval + 84 13 com.cycling74.message 0x13b86753 jmessage_atombuf_eval + 339 14 com.cycling74.message 0x13b86e30 jmessage_dobang + 123 15 com.cycling74.message 0x13b86f05 jmessage_mousedown + 205 16 com.cycling74.Max 0x000b8aa5 object_method + 963 17 com.cycling74.Max 0x000fd194 BoxComponent::sendMouseMessage(juce::MouseEvent const&, symbol*, double, double) + 264 18 com.cycling74.Max 0x00101457 BoxComponent::mouseDown(juce::MouseEvent const&) + 1247 19 com.cycling74.Max 0x00330410 juce::Component::internalMouseDown(juce::MouseInputSource&, juce::Point const&, juce::Time const&) + 584 20 com.cycling74.Max 0x0038e392 juce::MouseInputSourceInternal::sendMouseDown(juce::Component*, juce::Point const&, long long) + 96 21 com.cycling74.Max 0x0038ea38 juce::MouseInputSourceInternal::setButtons(juce::Point const&, long long, juce::ModifierKeys const&) + 380 22 com.cycling74.Max 0x0038eb74 juce::MouseInputSourceInternal::handleEvent(juce::ComponentPeer*, juce::Point const&, long long, juce::ModifierKeys const&) + 172 23 com.cycling74.Max 0x0038dc45 juce::MouseInputSource::handleEvent(juce::ComponentPeer*, juce::Point const&, long long, juce::ModifierKeys const&) + 75 24 com.cycling74.Max 0x00396289 juce::ComponentPeer::handleMouseEvent(int, juce::Point const&, juce::ModifierKeys const&, long long) + 103 25 com.cycling74.Max 0x004362df juce::NSViewComponentPeer::sendMouseEvent(NSEvent*) + 113 26 com.cycling74.Max 0x00436599 juce::NSViewComponentPeer::redirectMouseDown(NSEvent*) + 129 27 com.cycling74.Max 0x0042b9f3 -[JuceNSView_1_52_105_3 asyncMouseDown:] + 34 28 com.cycling74.Max 0x0042eade -[JuceNSView_1_52_105_3 mouseDown:] + 52 29 com.apple.AppKit 0x97b1da21 -[NSWindow sendEvent:] + 6968 30 com.apple.AppKit 0x97b18a0f -[NSApplication sendEvent:] + 4278 31 com.apple.AppKit 0x97a3272c -[NSApplication run] + 951 32 com.cycling74.Max 0x0043270f juce::MessageManager::runDispatchLoop() + 731 33 com.cycling74.Max 0x002c1f02 juce::JUCEApplication::main(juce::StringArray const&) + 68 34 com.cycling74.Max 0x002c2025 juce::JUCEApplication::main(int, char const**) + 73 35 com.cycling74.Max 0x0000db8b _start + 209 36 com.cycling74.Max 0x0000dab9 start + 41

    • Feb 19 2013 | 9:16 pm
      FYI, the serial #s for the kinects in question are: 167765324135 and 060706224435.
      I'm frequently quite dense, and I'm kind of hoping that this is the case here. Any help would be appreciated. Yes, I've gently asked Jean-Marc, but he's busy with other things right now.
    • Feb 19 2013 | 10:13 pm
      hey, i had a crash the other day with jit.freenect.grab as well, and contacted Jean-Marc Pelletier too. No idea if this is related ; still i use jit.openni, which is far more complicated to install, but seems to work without problem for me. I did obtain that kinect very recently, it's an xBox model, fwiw.
    • Feb 19 2013 | 10:19 pm
      what is the problem with jit.openni ? does it not work well on osx ? can't you use 2 kinects at the same time ?
    • Feb 19 2013 | 10:27 pm
      as far as i can tell, you cannot use more than 1 kinect with the mac version of jit.openni. if i'm wrong it will be a relief.
    • Feb 19 2013 | 10:27 pm
      oh, and i was able to successfully install jit.openni and make it work on these same machines. it's only jit.freenect.grab that's giving me guff.
    • Feb 20 2013 | 12:23 am
      An update: I suspect MS may have altered the innards of the Kinect. Confirmed that everything is totally fine with my older model (serial # 011227103635). I'm going to reach out to the libfreenect folks and see if they can replicate.
    • Feb 20 2013 | 10:37 am
      cool, i did think you could handle several kinects with jit.openni though... i would help if i could, but am not very good with the sources.
    • Feb 20 2013 | 3:13 pm
      OK, here's the deal: jit.freenect.grab as of version RC5 does not work with the new model of Kinects. You can tell the model number by looking at the bottom of the unit, at the upper right corner of the sticker underneath. If it says "model 1414" you can use the object. If it says "model 1473" then you should return it if you wish to work with multiple depth images on a Macintosh at this time. Should I learn that Dale has updated the mac version of jit.openni to provide this functionality, or that Jean-Marc has updated jit.freenect.grab, I'll try to remember to update this thread.
    • Feb 20 2013 | 4:27 pm
      thanks for the reporting joshua!
    • Mar 24 2013 | 12:47 pm
      Hey, Any news on this ?
    • Apr 09 2013 | 3:57 pm
      I have the same problem
    • Apr 21 2013 | 6:05 pm
      Good to hear that jit.openni works on all the models. I do hear and respect the desire for multiple Kinect support on it. I've read sporadic posts via google that with some C hacking they were able to use OpenNI and SensorKinect on 2 Kinects. So it may be possible to enhance jit.openni to use this same realm of hacks.
      Its a time/priority thing for me. I don't have the extra time to do the solo research and coding changes. What *is* possible is for anyone to enhance the code at https://github.com/diablodale/jit.openni. Its all up there. I could perhaps collaborate with someone and then merge back in the changes for which everyone to benefit.
      Any volunteers?
    • May 02 2013 | 7:07 pm
      I'm not able to use jit.openni with the new model kinect 1473 Does anyone on mac can use it ? I read about a partial support of the new model from libfreenect but i have to try yet
    • May 04 2013 | 12:10 am
      vichug above reported jit.openni did work with the new 1473 hardware. Did I misread that post?
      If there is an issue with that hardware, it will be due to be a limitation of SensorKinect. SensorKinect is the hardware driver which exposes the Kinect hardware to OpenNI. The most recent version of SensorKinect v0.93 has only preliminary support for the Kinect for Windows hardware. It could be possible that a yet newer version of Kinect hardware (e.g. 1473) is not yet supported. https://github.com/avin2/SensorKinect ** It is open source. What dev wants to volunteer, fork it, make the updates, and then release an update for SensorKinect? **
      All the software that doesn't use the officlal Kinect SDK is experiencing failures including libfreenect, Synapse, ofxKinect, NIMate, OpenKinect, and ROS
      I hope that soon, the devs which wrote the hardware drivers like SensorKinect (or other volunteers) can update the code to support the new hardware. It is this driver which is crucial. jit.openni is agnostic (doesn't care) about the hardware, it works on Kinect, Xtion, PMD Camboard, etc. All you need is a working hardware driver.
    • May 06 2013 | 10:22 am
      hmm i forgot to check the version number of that kinekt, and i don't have it under hands atm..; so sorry, i can't really help.
    • May 01 2014 | 7:04 pm
      was there any solution for the 1473 problem? or is the solution to return it?
    • May 01 2014 | 7:06 pm
      i'm working with max 6.1.7 on a mac osx 10.9.2. i am using jit.openni, not freenect