I am running SnapZ ProX on an Intel Mac (a native version, please!). It works fine much of the time, but I have been encountering problems when compressing and saving large files --- 1440x900 shrunk to 70%, 10 fps for about 4 minutes. Sorenson 3 or TIFF compression, has crashed with both so the codec isn't the problem.

When compression completes, I get a message:

The movie file 1106290143.rMi cannot be found. Without this file,
the movie cannot play properly.

If I look in the file folder, there is a nice weighty-looking file, approximately 12 MB, but with a .mo extension, not .mov. I've got plenty of disk, there's no other apparent failure.

It's a little strange that the file seems to be (trying to be) launched, because I have Launch after Save turned off, thinking there is some sort of "race" condition that the open starts before saving complete.

I have gotten some compresses of this size to work. But it's a coin flip. I really need a solution for this---I'd like to recover my existing file, and make sure it never happens again. I lose not only the several minute recording session (which can be a couple of takes to get right), but then it takes an hour or so compressing before you get a useless file. You can lose an entire day real quick, and be about ready to hose the whole thing down.

PS: In general, SnapZ needs to let you save the as-recorded raw data separately, then be able to compress and recompress it a few times until you get it right.

Hello Russ,
You can find that answer as well as many others in the FAQ in the future. Please give this a shot:

This should be a very rare occurrence. But if any changes are made to the codecs available to QuickTime, either through upgrading QuickTime, or installing third party software that includes codecs, QuickTime may need to be explicitly told which codec to use to save out the movie.

1. Invoke Snapz and press command-Q to quit Snapz. If you can not invoke Snapz, open the Activity Monitor found in your Utilities folder. Look for a process named "Snapz Pro X", select it, and then select "Quit Process".
2. Remove the Snapz preference file "com.ambrosiasw.snapz.plist", which is located in the Home/Library/Preferences folder
3. Reboot your machine
4. Invoke SnapzProX 2 and record a short movie file. When you get to the Save Movie dialog, click on the Settings button next to the video track. Change the compression codec selected to any of the others available. Click on OK, and then click on Save.
5. After this is done, you should be able to use any of the codecs.

There is a bug in Apple's H.264 codec as well. If you choose this codec, do not use keyframes! Please let us know if you have further problems.

Hi Evan-

Thanks for responding, but the response doesn't match my problem at all. I'm haven't installed anything, and I said I've used several codecs. The codec runs, it's not like it couldn't be found---it runs for an hour before the problem occurs. I've been capturing and saving clips, I can do shorter and smaller ones. It's the big ones that really count that failed.

How can I recover the file?
How can I make sure this does not happen?

Hello Russ,
My response will take care of the ".mo" instead of ".mov" issue. I would recommend giving it a shot regardless.

Unfortunately, the file in question can't be recovered. I wish I had a suggestion on how to prevent it in the future, but I don't. Please let us know how it goes

Reseting the prefs as described had no effect other than making me re-set them.

Further testing has revealed repeatable failure modes even with short clips as follows. Please try to reproduce. Running on 20" core duo imac with 1.5 GB. Sorenson 3 encoder at medium setting, 10 fps, key frames every 240 frames, 1440x900 capture window, with default audio settings 22KHz 16b mono

Testing proceeds using "testing 1 2 3" clips of a few seconds long. Save to disk. OK
Record another clip "testing 4 5 6", save. FAILS 1106290142.rMi not found.
command-Q SnapZ
restart SnapZ manually
test 8 9 10. Succeeds
test 11 12 13 Fails
test A B C Fails
command-Q and restart
test 14 15 16 Succeeds
test D E F succeeds
test G H I fails
command-Q and restart
test 17 18 19 Succeeds
test 20 21 22 Fails
command Q and restart
test 23 24 25 succeeds
etc


The first time after starting SnapZ Pro looks to always work for short clips, at about 10 out of 10 certainty.
Second and following attempts succeed at about a 50% level (maybe 3 for 6 certainty)
Once a failure occurs, succeeding attempts will fail
Command Q and restart restores operation (no reboot or prefs reset required to get working)

Further complicating this picture: command-q and restarting snapz, then recording my full length clip ---- it fails anyway!!! Went zero for two at about an hour for each good take attempt apiece. So it is basically unusable.

So far I've been unable to reproduce the problem on the closet machine I've got which a Mini core duo. I'm using the same settings as you've outlined. Where do you have selected in the "Send to" pop-up menu? That file that can't be located is a temp file.

pictures. also 70% shrink. automatic naming. Deleting a take increases the probability of a problem. Is there a way to save the raw video&audio data, to be able to try compressing it more than once until successful? (useful in general to experiment with settings)

I find that I'm getting the missing file error message when SnapzProX trys to overwrite an existing file:

Start up a recording, tell SnapzProX to save it to the file foo.
Record a movie.
Stop recording.
All is good.
Start up a recording, tell SnapzProX to save it to foo, by leaving the file name at the last used file name.
Record a movie.
Stop recording.
QuickTime complains about not being able to find the movie content when the movie is being saved.
Throw foo in the Trash.
Record a movie.
Stop recording.
All is good.

Perhaps this is the problem. I'm using a mac mini dual core Intel.

A followup:

Record a movie to the file foo. After QuickTime plays the movie, leave QuickTime open, with the movie showing.
Throw foo in the Trash.
Record another movie to the file foo, again.

After the "it's a wrap" statement, QuickTime plays the old foo movie in a new window, but double-clicking the new foo file shows the new movie. It seems there is some confusion about files.

There's no confusion here - at least not from the view of the computer.

What happens is, that Mac OS X has a reference to the file that's independent of where the file is actually stored. Thus, when QT opens the file it gets hold of this reference. Now, you thrash the file, but the reference stays the same - the file is just located in a new place.

True enough, but QuickTime should not be opening the old file. As far as I would guess things should work:

SnapzProX saves the movie to a scratch file, unrelated to the old or new files named foo
Someone, either QuickTime or SnapzProX takes the scratch file and repackages it as the new foo file.
The new foo file is handed to QuickTime for playing.

Since this is the new file, QuickTime should not be opening the old file from the Trash. I'm guessing this is related to the problem of QuickTime being confused when SnapzProX tries to make a movie which has the name and location of an already existing movie, because the symptoms are similar.

Just a thing (maybe it help you)
Be sure to have enough space on your HD for the video. Sometime my HD is full, and the compression end normaly, but my video can't be open.