"There was a problem taking that shot"

[jacobrosenthal]

Getting reports, so far only from macbook pros, of "There was a problem taking that shot" error messages occasionally, instead of photos.

Related to #22 maybe?

Test if #20 fixes it maybe?

Some logs from when it happened to @phated once
10/26/13 1:17:43.008 PM memoryio[12536]: ImageIO: CGImageDestinationAddImageFromSource image 0 of source is nil1:18 PM
10/26/13 1:17:43.008 PM memoryio[12536]: ImageIO: CGImageDestinationFinalize image destination does not have enough images
10/26/13 1:17:43.009 PM memoryio[12536]: **Could not create data from image destination **

I've experienced this as well:

Error Logs: https://gist.github.com/bowerman/7269449

[jacobrosenthal]

Very helpful logs.

Look no frames coming in when failing! ( a period in logs is a frame coming in)

The open source image snap source code we utilized would just try to get frames forever. We saw this lock machines up with 100% utilization and our solution for 1.0.1 was to just try to get 1 frame thinking not getting a frame was rare (and it seems to be very rare on the macbook airs as so far we've only seen this on pros)

I made a branch that tries to say 100, that WILL occasionally spin long enough to get a frame, though it will ALSO occasionally fail without getting a frame.

If it always failed I would say we're swallowing an error someone during startsession where we subscribe to get frames back, but since we do get frames back after x tries it seems like the system just decides when to give you frames.

I dislike it greatly but a fix may really be to attempt for X times or for X seconds and give up.

Have you checked out:

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/QTKitApplicationProgrammingGuide/UsingQTKit/UsingQTKit.html

On Friday, November 1, 2013 at 12:02 PM, Jacob Rosenthal wrote:

Very helpful logs.
Look no frames coming in when failing! ( a period in logs is a frame coming in)
The open source image snap source code we utilized would just try to get frames forever. We saw this lock machines up with 100% utilization and our solution for 1.0.1 was to just try to get 1 frame thinking not getting a frame was rare (and it seems to be very rare on the macbook airs as so far we've only seen this on pros)
I made a branch that tries to say 100, that WILL occasionally spin long enough to get a frame, though it will ALSO occasionally fail without getting a frame.
If it always failed I would say we're swallowing an error someone during startsession where we subscribe to get frames back, but since we do get frames back after x tries it seems like the system just decides when to give you frames.
I dislike it greatly but a fix may really be to attempt for X times or for X seconds and give up.

—
Reply to this email directly or view it on GitHub (#24 (comment)).

[jacobrosenthal]

Yeah I've worked with that guide. Checked once again I BELIEVE I'm following it to a T. Very frustrating. I don't see any way forward except trying X times. Whats do we think the upper limit of X should be. 10 seconds worth? Anymore than that? 30 seems long...

[jacobrosenthal]

I think switching to nscontrol queues finally licked this. 1979edc