QT Movie File Nightmares

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" then

In 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" then

as 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.

Have you tried this? I ran this code with a movie file and it came back blank

[code] dim f As FolderItem = GetOpenFolderItem(“”)

MsgBox f.MacCreator + " – " + f.MacType[/code]

Then I ran this code and thereafter the above started outputing “bbbb – MooV”

[code] dim f As FolderItem = GetOpenFolderItem(“”)

f.MacCreator = “bbbb”
f.MacType = “MooV”[/code]

MacType and MacCreator have been deprecated for ages. Have a look in the documentation what an UTI is.

if newFile.MacType="Moov" then

Why do you need this?

I can play .mov Videos with MoviePlayer and with HTMLViewer .

Will that was perfect. Cooked a quick little drag and drop app that we can use on the Movie files to repopulate the mac creator and mactype properties, which saves having to dig up an old version of RB / Xojo to do a one off build that would still run under 10.5.x and then having to manually install said build on hundreds of machines remotely around the world and redo the preferences and whatnot over SSH.

Thanks so much.

As for Beatrix / Axel, you kinda of missed the point and didn’t read my OP very close at all from the looks of things. I’m painfully aware they’re deprecated and am additionally very much aware of the documentation thank you very much. However the client could care less, they don’t want to spend any $$ upgrading either the OS’s or the hardware, so all the knowledge of the deprecations in the world doesn’t help when you HAVE to have your app running under 10.5.x - 10.10.x on every vintage of hardware produced between 2001 and now. And yes, I have RB apps that old out there running. I’ve got a few of them dating back to 2001 having amassed literally millions of runtime hours without a single crash.