kylemcdonald / ofxEdsdk

Interfacing with Canon cameras from openFrameworks for OSX. An alternative to ofxCanon and CanonCameraWrapper.
Other
111 stars 51 forks source link

tons of thread errors #17

Closed kylemcdonald closed 9 years ago

kylemcdonald commented 10 years ago

was just testing this today and there are a ton of "mutex locked outside the thread" errors.

i also think the thread is getting stopped incorrectly. need to double check.

ofZach commented 9 years ago

(just confirming that I've seen alot of thread errors also... digging into this. for sure the closing is bad, but I'm seeing more general freezes / instability)

kylemcdonald commented 9 years ago

thanks @ofZach, please share anything you find! i haven't looked into this for a while, but i know a lot of people are still using ofxEdsdk successfully in their projects.

ofZach commented 9 years ago

yeah I'm running some tests now, there are certain error conditions that might need to be handled more gracefully (like if you can't take a picture, ie, full card, etc, you get stuck "trying" to take a picture).

kylemcdonald commented 9 years ago

that would be great. i tried to design the lib in a way that made the errors more C++-y and easy to use with try/catch https://github.com/kylemcdonald/ofxEdsdk/blob/master/src/EdsWrapper/EdsWrapper.cpp but not all the errors are being caught right now, just the ones i've run into before.

ofZach commented 9 years ago

I think the problem is something like this:

https://github.com/kylemcdonald/ofxEdsdk/blob/master/src/ofxEdsdk.cpp#L369-L377

even if you get to the error, you don't set "needToTakePhoto" to false so you are continually hitting this error -- ie, you said take a photo, it can't, but it's basically trapped trying to take a photo continually... will dig in a bit more and try to understand why things are freezing for me.

kylemcdonald commented 9 years ago

that makes sense. this was written as i was just starting to get a feel for threading in c++, so that code looks suspicious to me now.

ofZach commented 9 years ago

just confirming that I am definitely seeing this in the venue I have the camera installed in, I basically get stuck in a loop that draws endless errors, it doesn't seem to ever recover enough to take a picture, even if the image changes....

[ error ] Error while taking a picture: EDS_ERR_TAKE_PICTURE_AF_NG inside SendCommand()
[ error ] Error while taking a picture: EDS_ERR_TAKE_PICTURE_AF_NG inside SendCommand() 
[ error ] Error while taking a picture: EDS_ERR_TAKE_PICTURE_AF_NG inside SendCommand()

going to look at a better error system and also what the auto focus work in another issue / branch might do to help me specifically.

kylemcdonald commented 9 years ago

also: which camera model are you using, which mode is it in, and which EDSDK version?

ofZach commented 9 years ago

edsdk 2.14.0.3 (this is oddly nowhere in the code for the sdk but in the plist of the framework) camera = rebel sl1 mode= manual

thanks! investigating...

kylemcdonald commented 9 years ago

i switched the closing from using the destructor to using a close() that should be called on exit(). in my experience threads cannot be stopped at the same time they are being destroyed, because there is no guarantee about the order of data being deleted. this was a mistake on my part the first time i implemented it, and i think some other addons i've made still have this mistake.

however, regarding the ofLogVerbose() messages, i think this is actually something that should change in OF. right now bool ofThread::lock() says:

    if(isCurrentThread()){
        ofLogVerbose("ofThread") << "- name: " << getThreadName() << " - ofThread locked its own mutex.";
    }else{
        ofLogVerbose("ofThread") << "- name: " << getThreadName() << " - External thread locked the ofThread mutex.";
    }

and this is really way too many messages, not an error.