-
Insight into FCP and Compressor Problems
If this info is common knowledge, then please feel free to to delete this post.
I have used FCP and Compressor for a few years starting with version 4.5 of FCP and whatever version of Compressor came with that. The two programs at best are “bad room-mates.” At least they pay rent consistently, but never on time, never without a fight, and the apartment is always a mess.
Sadly with each iteration of program upgrades, somethings are improved but fundamentally things do not get better. A good example is now FCP7 and Compressor 3.5 do not freeze upon sending renders from FCP, but now at least FCP sends back an error that it ‘quit’ – although it doesn’t really.
The problem I have seen consistently is the loss of control of the two programs during the handoff. And today I might have gleamed an insight into the issue.
I am pretty sure, there is a flaw in how the programs are using disk space. Since I am now working exclusively in HiDef, ProResHQ, I am using files that are anywhere from 12 to 48 gigs in size. My current setup is a little wacky in that I have a 64 gig SSD drive as a boot drive and all my user info lives on a 1TB internal Hard Drive. My video files live on a 8TB array. Without going into the thousands of details of my troubles, it appears these programs are reserving space on the hard drives, running out and never freeing it up properly. (I had these similar problems with an iMac that had an internal HD of 250 gigs so I am pretty sure this is not an SSD drive problem but a free space problem).
1. Qmaster and the cluster function is the first issue. The default temp render files are set to the internal boot drive – not even to the user folder on my bigger 1tb drive. I found when I changed Qmaster settings to a drive with enough free space on it, I could get the “cluster function” to work when I use Compressor as a stand alone application. To change the location of the temp file, open the Qmaster control panel and chose The Advance button up top. With this set to a drive with enough space on it, now I can consistently use a multi-core one computer cluster. Remember, no FCP involved at this point
2. Today, I tried going back to the ‘normal hand off between FCP7 and Compressor with “send to compressor” and use my multi-core one computer cluster but I experienced that ‘final cut quit’ error again. Upon further inspection, there was 16 gigs of lost space on my internal SSD drive. Simply by turning on the Finder’s Calculate size, I saw FCP itself in the applications folder had ballooned up to 16 gigs! As a matter of fact, FCP7 wouldn’t even quit because it kept throwing up a warning box that I had to quite Compressor first as there was a job still running. However compressor and Batch Monitor had reported the job had failed. I had to force quit FCP. Upon reboot, FCP7 app was still 16gigs. So, right Click/Control Click the FCP app to open up its contents revealed that in the MacOS folder was a render folder with 15.2 gigs of material in it. There was only another 15 gigs free on the SSD drive. So I am guessing this is the culprit of why the handoff keeps bogging down. The drive where FCP lives is not big enough. I wonder if I can just move the app? Sadly, I do not know of any settings in FCP that will allow me to effect where these temp renders are getting handled. My scratch disk folder is on the 1TB user drive. (The real issue is why if FCP shoving render files into the app itself. Although that might make things neat, its not smart.)
Well anyway. Hopefully this insight leads to some better workarounds for people out there. Please post any solutions you might come up with. It seems like one might just be installing a 2TB boot drive.
-
4 Replies
-
Hey Doug,
that’s some interesting discoveries. I can’t say I’ve experienced the same issues you’ve been having with compressor. Have you tried setting qmaster to never use cluster storage? I’ve never noticed compressor creating temp render files inside the fcp app package, but I’m going to check that out when I get home. Could you have the “output” directory set to “source”?
The \”send to compressor\” option has been fairly reliable for me… But I haven\’t used compressor 3.5 a lot.
I suppose you could experiment with changing the temp render dir inside the fcp App package to a sym link pointing to one of your arrays. But that would be playing with fire, IMHO.Matt Lyon
Editor
Toronto -
Hi Doug,
I just noticed that and started looking for info. I am converting MP4s to AppleProRes HQ in order to edit them through Compressor. Even though I am sending them directly to an external drive, it still fills up my internal (boot) drive.
Did you ever figure out a way around that?
Many thanks.
Stan
-
I’ve noticed these problems too. My workaround is using Adobe instead. FCP is a quick solution for a lot of things. Same way with compressor. It might take a bit longer to set up Adobe renders or edit projects the way you want them, but it’s worth the extra 15 tedious minutes to save on 4 hours of wasted render times and crashed programs! When it comes to working well between applications, Apple could stand to improve A LOT while Adobe is the best in the industry.
md
-
I have a serious problem with FCP7 and Compressor3.5. I’m not able to export my sequence to the Compressor It doesn’t give me the option as it used to be with older versions. Can anyone help me?
It will be very much appreciated.
Carlos
Reply to this Discussion! Login or Sign Up