When I sat down tonight to work on my app, it just kept crashing. Seems a new exception, QTMovieInitializedOnWrongThread, was added to QuickTime. Searching on ADC produced 0 results. Google couldn’t even find anything about it. Fortunately, the error needs little explaining: I need to initialize my QTMovie object in the main thread. That’s easy enough for my scenario. done.

If my app was shipping, I’d have mud on my face. I guess I’ll have to scrounge up the 500 clams for the select ADC membership so I can get more of a heads up when these things are coming. We’ll see.

For now I need to figure out if I missed something that said QTMovie initialization needs to be done in the main thread and why.

update: Thankfully, I’m not alone. Felix Schwarz writes:

In short: every developer who wants to background Quicktime operations in threads in order to not block the user interface for the duration of Quicktime calls has a tough time.

update 2: Tim Monroe of QT engineering states:

However, we have recently uncovered some issues when working with QTMovie objects on a background thread, even when doing things the “right way”. We are hoping to provide a more thread-safe QTKit soon.

Although I like my current use of NSThread’s, I can’t afford to test, debug and deal with “issues”. So, back to the drawing board. Right now I’m looking at using a helper application (that’s actually how QuickTime Player does it’s export) communicating via distributed objects. Live and learn.

This entry was posted on Wednesday, January 11th, 2006 at 12:14 am and is filed under QuickTime, Code. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.