Exporting Reference Movies with Lion and QT X

Question

Has anybody else had issues exporting Reference Movies from FCP7 under Lion?
When we open a Reference Movie created with FCP7/Lion in QT X 10.1 (the version that ships with Lion), we're only able to see the first frame of the movie, followed by black/blank video, and audio only.
Curiously, QT7 (on Lion) and QT X 10.0 (on Snow Leopard) are able to play these movies without a problem.  However, a number of 3rd-party applications and devices that we use in our facility (most notably an Omneon Spectrum) choke on the reference movies in a similar manner to QT X 10.1.
We've got a support ticket open with Omneon, although they claim to have never heard of the problem, and are currently picking their way through the issue as well.  However, there are scattered reports of others who are having similar problems.
For the sake of thoroughness, it's worth mentioning that this is a brand-new Mac Pro with Lion 10.7.2, and FCP 7.0.0; both fresh installs (apparently downgrading to SL is unsupported on this machine).  We tried patching FCP to 7.0.3 with Pro Application Update 2010-02, which did not resolve the problem.  We've since reverted to 7.0.0, to rule out the patch as the culprit. The reference movies in question do not contain any edits that would require a render, and everything's stored on a NAS that's accessible to the whole office (hence the fact that we're able to view the files on our Snow Leopard machines.
Picking apart the reference movie using Apple's Atom Inspector shows one curious detail in the alias data inside 'dref' atom inside of the reference movie (which is how QT figures out where the original media is).  Rather than being a simple file pointer, the alias actually contains a whole bunch of information, including the "relative" path to the video data, relative to the original location of the reference movie, as well as the absolute path of that file, starting from the root of the filesystem.  Both of these paths are presented in "Mac" and "Unix" formats, ie:
Mac:   volume:folder1:folder2:filename
Unix: /volume/folder1/folder2/filename
Key difference is the use of colons, rather than slashes to separate folders in the path.  At least, that was the key difference prior to Lion.  We've noticed that, while the SL machines export reference movies with paths that resemble the above, our Lion machine generates:
Mac:   volume:folder1: folder2: filename
Unix: /volume/folder1/folder2/filename
(Notice the spaces)
When we attempt to play the movies with our Omneon applications or in QT X 10.1, our NAS throws a whole bunch of 'File not Found' errors.  Presumably, those spaces are the culprit.  Removing the spaces with a hex editor completely mangles the QT movie, and renders it compltetely unplayable.
Unfortunately, the alias data inside the dref atom doesn't appear to be a standard Mac OS alias, and the only documentation of the alias file format (linked above) is hilariously out of date.  Presently, the format is undocumented, and it appears that developers are discouraged from interacting with the files directly.  In other words, I have no way of knowing whether or not the spaces are actually significant, or are a completely innocuous and documented part of the file format.
Has anybody encountered anything similar, or found a solution?  I'm at a bit of a dead-end here, and would welcome any advice.

Answer 1

I totally understand where you're coming from; Apple's support of some of QuickTime's more advanced features has unfortunately been waning for some time now. 
Avoiding the buggy parts of the program is always a good strategy, although the ability to quickly export reference movies is something that is absolutely vital to our workflow.  Simply put, losing these files is an absolute dealbreaker.
Two things seem to be going on... FCP on Lion appears to be generating slightly malformed reference movies, and QT X 10.2 seems to be freaking out when it tries to play back those movies (while prior versions are seemingly able to work around the problem).  I suppose this could have something to do with the introduction/evolution of QTKit and AV Foundation on Lion, although I'm surprised that this would be affecting FCP7, which was built around older APIs.