Ok, so I have a whole mess an app deployed of varying vintages. The oldest is running under 10.5.8, all the way through to 10.10.x.
The app plays a single QT Movie which gets updated periodically. In order to play the most recent movie the app checks the contents of a folder, and puts everything that isn’t a QT movie into an archive list, and then goes through whatever QT movies happen to be in the folder, and keeps the most recent file mod date one as the file to play, and then moves all the non QT movie files and the older versions of the movie to an achieve folder. This has been working flawlessly for years.
Until last week. We got a new version of the movie to deploy a few weeks ago, and that one played fine. Then the client decided they didn’t like a color or something in it, and sent a new version of the same thing, and that’s when the problems started.
Every version of the app decides that the new QT file isn’t even a movie and archives the entire mess to the archive folder at which point the app plays an embedded movie bundled with the app that’s normally only supposed to be seen on it’s initial launch.
After digging out the old projects and fixing all the intervening deprecations etc just to get it to run in the Xojo 2015 R1, I find the crux of the problem:
if newFile.MacType="Moov" thenIn stepping through it, and looking at the folder item in question, both the MacType and Creator Codes come in as blank.
This made me assume that whatever they were using to author the QT movies in (most likely FCPX) no longer put the MacType and Creator codes into the file, but in checking them with 2 different versions of FileBuddy, both the mactype and creator code show as being present, which is even stranger, as that’s the only place in the code that would cause the movies to end up in the archive list.
When I step through the code again with the previous version of the files they sent just a couple weeks ago, the mactype and creator codes come in correctly, so obviously something has changed in the QT file itself, even though FileBuddy shows the Mactype being there, the RB and Xojo apps aren’t reading it.
The newer cocoa version of the App uses
if newFile.Type="video/quicktime" thenas the file type check and that works, but I’ve got all these older versions under every version of OS X from 10.5.8 through 10.10.x out there, and the majority of them are running 10.5.8 and 10.6.x.
We’ve been after them for years to update this stuff but they don’t want to spend the money to do so, and now their own content is breaking the app.
Has anyone ran into this? My guess is they either updated the content authoring machines from 10.10.2 to 10.10.3 or updated FCP to the latest and that’s what’s causing the newly authored QT Files to fail the MacType check.
My hope is there’s something we can do to the files themselves to get them to pass the check, otherwise we’re going to have to do a rebuild on the app so it will still run under 10.5.8. I don’t even know what version of RB or Xojo will build an app that will run under 10.5.8.
This might be related in some odd way to the pulling of the QT API’s for the mac app store on the authoring app, I have no idea. All I know at this point is it will be a major PITA to redeploy a different version of the App just to change the file type check code to hundreds of machines all over the world.
The easiest solution would be to find some way to get the QT mov files “fixed” so the old code will read the mactype correctly and not archive them, but I can’t figure out what’s wrong. As I mentioned, when I do a get info with file buddy it shows the mactype and creator code as being correct, but for some reason the RB and Xojo built apps don’t.
This is just beyond puzzling.