Compressor 4.1 waiting....

How are you bringing the h.264 file into Compressor? If you're using Send-to from FCP, instead export a Master File. (I would suggest a Pro Res file.) Then use that as your source file.

If you're already working with a stand-alone file, and it originated from a FCP project, export a Pro Res version and try that. As a practical matter, you won't lose any quality and it will be a quick export.

If none of this works or applies to you, go into you Home Folder Library>Applications Support and trash the Compressor folder (with Compressor closed, of course).

Russ

Hi Ed, just noticed this yesterday that Compressor.app's qmaster (buried these days) seems to be somewhat particular about the access (ACE) of the MOUNT of the cluster storage. You've probably noticed too that the cluster storage in V4.1 currently IS SET to access the path at /Users/Shared/Library/Application Support/Compressor/Storage only and ther's no parm to change it as there was prior to compressor.app V 4.1

Look here in using console.app ~/Library/Logs/Compressor:

• contentcontroller:com.apple.qmaster.contentagent.log
• jobcontroller:com.apple.compressor.cluster.admin.log
• qmasterd.log
• requestprocessor:com.apple.compressor.contentcontroller.log
• servicecontroller:com.apple.stomp.transcoder.stomp.log
• servicecontroller:com.apple.stomp.transcoderx-1.log
• servicecontroller:com.apple.stomp.transcoderx-2.log
• servicecontroller:com.apple.stomp.transcoderx-3.log
• servicecontroller:com.apple.stomp.transcoderx.log
• unfsd.log

and also system.log

Look for:

1. error: mkdir failed for path = [/Users/Shared/Library/Application Support/Compressor/Storage/628FAF27-3CA67A97/shared]"
2. nfs server macpro-nehalem-16core.local:/Users/...../Library/Application Support/Compressor/Storage/628FAF27-3CA67A97/shared: can not connect, error 65

Conditions like this will cause the batch submissions to wait. Others will as well. i.e can't mount, unable to WRITE to it , not avalable etc...

Also check for a .qsubexp directory in the TARGET folder of you your transcode. This has qmaster plists and some state into . It usually is built then purged by qmaster. You can clean it up as follows in these steps:

1. stop all current batches in Compressor.app V4.1
2. disable the SHARING host the current host in the compressor.app V4.1 (set slider to off)
3. Quit compressor.app v4.1
4. launch the Terminal.app
   • cd [to the target directory were the target transcode is being written} .. .e.g cd /volumes/diskarray/job123_compressor_distribution
   • enter rm -rf .qsubexp to remove the .qsubexp folder (note it's hidden OSX finder)
5. In addition, attempt to REMOVE the contents of the /Users/Shared/Library/Application Support/Compressor/Storage folder if you can. Attept tp empty the trash too.
6. verify the ACL for the (+i show permissions) for /Users/Shared/Library/Application Support/Compressor/Storage. (NOTE: if you are using OSX 10.9 server, then make sure its available in FILE SHARING... see permissions theere)
7. restart Compressor and ENABLE the sharing and the CLUSTER again
9. .. resubmit your job.

Post your results for others to see.

HTH 🙂

Warwick

Hong Kong

Hey guys,

I just wanted to jump in on this thread (having run into the same issue) and a simple delete of the Compressor folder in Application support worked fine.

I had a network disturbance in the middle of transcoding and I guess for whatever reason, Compressor "Remembers" the failure, and won't write if it's accessing either the same failed drive or directory... maybe ANY directory, but I didn't experiment.

I didn't try to delete the "storage" folder... I just got rid of the whole thing... next time I'll try just the storage to see if I can keep my presets (which I'm happy to let go of in order to see the program funciton again).

---Trav

Worse case scenario, you should be able to close Compressor, remove ~/Library/Application Support/Compressor, then restart and it should fix most things. Compressor has processes that continue running when you close it if sharing is on, which is why I recommend the reboot, unless you are comfortable doing "ps -alx | grep -i compressor", then kill all the processes that have the /Applications/Compressor.app path.

• So turn off sharing.
• Close Compressor.
• Remove ~/Library/Application Support/Compressor. If you have custom or plugin settings, copy the settings folder first.
• Restart.

Hi Trav, yes indeed your reference to "remembers" ..i.e. the STATE INFORMATION that has been mention many many times in this forum. is...

..... I guess for whatever reason, Compressor "Remembers" the failure, and won't write if it's accessing either the same failed drive or directory...

maintained in one of two places:

1. ~/library/application support/compressor/storage/jobs/xxxxxxx-yyyyyyy (where xxxxxxx yyyyyyy is the current cluster ID. There may be several active and stale. We usually have two active.

   sub directories Jobs Shared and sometimes hidden . files such as .TemporaryItems etc etc

2. /Users/shared/library/application support/compressor/storage/xxxxxxxx-yyyyyyy (also where xxxxxxx yyyyyyy is the current cluster ID. There may be several active and stale)

   not always yet sometime .hidden files to maintain some sharing handshake.. will stand corrected.

This is why when you brute force PURGE these structure, Qmaster/compressor is "reset' anew in a sense. You also need to review similar structures on other service nodes (other hosts) and perform the same ritual on these as well else this state information may persist and become quite bothersome.

As I mentioned earlier and in many posts, one needs to rm -rf these objects and rip them out from underneath compressor/qmaster structure as they are serialised when using the "empty trash" procedure. They won't always DELETE because they are in use. Qmaster will rebuilt these structures immediately.

Oh make sure you DISMOUNT (unmount/unshare) any of these file structures folders if they are specifically MOUNTed (network or direct via SAN) on other hosts (service nodes). As always Qmaster will recover.

Other posters have proposed a shutdown/restart (reboot) or terminate qmaster compressord subtastsks to release this serialisaion. Good idea, Yes this will work ofcourse yet is high disruptive.

Summary:

I.M.O , For most Compressor.app V4.1 there's usually NO NEED to brute force/harshly (add your own superlative) DELETE the whole Compressor.app V4.1 (Dec 2013) ~/library/application support/compressor nor /Users/shared/library/application support/compressor structures to resolve your issues. It certainly works and used to work well in those unstable days of Qmaster. There's some much information by many experienced posters on these forums to reolve issues that will certainly return unless they can be readily resolved without a workaround. .

However it doesn't resolve the original issue and as we know can be disruptive if all the clusters (two in out=r case) are knocked out when in fact the jobs are running ok.

You can easily navigate the qmaster HISTORY structure in these folders and surgically remove bothersome jobs.

HTH

Post your results for others to see.

warwick

Hong Kong

Hi Warwick,

I have the same problem with Compressor 4.1.1 when enabling additional Compressor instances (No Shared computers groups created, Allow other computers to process batches on my computer is set to OFF), the batch is always stuck on waiting. When not using additional instances, Compressor is working fine. I've searched the Console and have a log in jobcontroller/com.apple.compressor.cluster.admin.log:

<mrk tms="416746509.667" tmt="03/17/2014 11:55:09.667" pid="716" kind="begin" what="log-session"/>

<log tms="416746546.757" tmt="03/17/2014 11:55:46.757" pid="716" msg="Turning on unmanaged services for [This Computer]"/>

<mrk tms="416746546.757" tmt="03/17/2014 11:55:46.757" pid="716" kind="begin" what="CJobControllerService::publishClusterStorage"></mrk>

<log tms="416746546.758" tmt="03/17/2014 11:55:46.758" pid="716" msg="Cluster storage URL = file2nfs://localhost/Volumes/Data%20X/Witcher/Library/Application%20Support/Com pressor/Storage/D1CA84EA-EC22AB14/shared/"/>

<log tms="416746546.758" tmt="03/17/2014 11:55:46.758" pid="716" msg="Publishing shared storage."/>

<mrk tms="416746547.794" tmt="03/17/2014 11:55:47.794" pid="716" kind="end" what="CJobControllerService::publishClusterStorage"></mrk>

<log tms="416746547.794" tmt="03/17/2014 11:55:47.794" pid="716" msg="CJobControllerService::startClusterStorage() failed: mkdir failed for path = [/Users/Shared/Library/Application Support/Compressor]"/>

It seems I've got the issue of not being able to MKDIR... WRITE. There is no .qsubexp folder in the target locations (tried different ones). I've tried to delete the whole compressor folder (not in Finder) in

/Library/Application Support/Compressor/, restart, reinstall, even creating another account (idea in different post) is not working. Do you think there can be a solution to this problem?!

Thank you very much!
Tom

Yes... give up. It never works correctly, and when it does, it's only temporary.

You will fix it 30 times, only to have to fix it 30 more. You're better off with a more reliable program.

You need to trash the app support folder on all of your computers, and the preferences while youre at it (using compressor repair).

My recommendation would be to stop wasting your time.

No question that some folks have had recurring problems and that permanent fixes for them have been elusive.

Others have found the new version to be faster and more stable than previous versions.

Just to see that trashing the Applications Support folder is extreme. Trashing certain sub-folders in Applications Support/Compressor can sometimes be worthwhile.

Russ

I had it working... then it stopped... then I got it to work again.... maybe 10 times.

Then it stopped working entirely and no amount of fixing, deleting, or changing of options got it back.

I wasted COUNTLESS hours, and I get faster as well as higher quality results using a single computer encode with a different program.

Do yourself a favor and let it go.

Witcher11 wrote:

<log tms="416746547.794" tmt="03/17/2014 11:55:47.794" pid="716" msg="CJobControllerService::startClusterStorage() failed: mkdir failed for path = [/Users/Shared/Library/Application Support/Compressor]"/>

It seems I've got the issue of not being able to MKDIR... WRITE. There is no .qsubexp folder in the target locations (tried different ones). I've tried to delete the whole compressor folder (not in Finder) in

/Library/Application Support/Compressor/, restart, reinstall, even creating another account (idea in different post) is not working. Do you think there can be a solution to this problem?!

Thank you very much!
Tom

The bolded part is the problem. Make sure you are looking in /Users/Shared, and make sure you have RW permissions on Library and Library/Applications Support. You can do it using Finder or Terminal.

ex: sudo chmod -R 777 /Users/Shared/Library

Hi guys, thanks so much for your help! I know I should give up, but I still want to give it a try, when I've paid for the application. I've changed the permissions and now there's another error in Console showing up, could you please help me again? (My goal is to be able to use multiple instances of Compressor - 3 in my case, to speed up transcoding. Nothing else).

<log tms="416826384.103" tmt="03/18/2014 10:06:24.103" pid="2324" msg="Turning on unmanaged services for [This Computer]"/>

<mrk tms="416826384.103" tmt="03/18/2014 10:06:24.103" pid="2324" kind="begin" what="CJobControllerService::publishClusterStorage"></mrk>

<log tms="416826384.103" tmt="03/18/2014 10:06:24.103" pid="2324" msg="Cluster storage URL = file2nfs://localhost/Volumes/Data%20X/Witcher/Library/Application%20Support/Com pressor/Storage/D1CA84EA-EC22AB14/shared/"/>

<log tms="416826384.103" tmt="03/18/2014 10:06:24.103" pid="2324" msg="Publishing shared storage."/>

<log tms="416826384.109" tmt="03/18/2014 10:06:24.109" pid="2324" msg="Subscribing to shared storage, local path = /Users/Shared/Library/Application Support/Compressor/Storage/D1CA84EA-EC22AB14/shared"/>

<mrk tms="416826384.122" tmt="03/18/2014 10:06:24.122" pid="2324" kind="end" what="CJobControllerService::publishClusterStorage"></mrk>

<log tms="416826384.122" tmt="03/18/2014 10:06:24.122" pid="2324" msg="CJobControllerService::startClusterStorage() failed: CNFSSharedStorage::_subscribe: command [/sbin/mount Mac-Pro.local:/Volumes/Data X/Witcher/Library/Application Support/Compressor/Storage/D1CA84EA-EC22AB14/shared] failed, error = 2"/>

Thank you so much!

/Volumes/Data X/Witcher/Library/Application Support/Compressor/Storage/D1CA84EA-EC22AB14/shared

Is this the actual path? This looks odd since its not a home directory, and a non boot volume wouldn't have this file structure.

You should start over. Open Compressor's preferences and turn off sharing, then close Compressor. If you dont have custom settings you want to save, you can

rm -rf ~/Library/Application Support/Compressor

If you do, go to ~/Library/Application Support/Compressor and delete everything except the Settings folder. Now do this:

killall cfprefsd

defaults delete -app Compressor

Optionally restart if you can, or copy and paste exactly:

for pid in `ps -ax | grep Compressor | grep -v grep | awk '{print $1}'`;do kill -9 $pid;done

Now open Compressor, and just enable your additional instances, nothing else. Now Copy a clip to your ~/Movies directory, and use that as your source and submit a batch. Depending on what happens next determines what to do next. Post errors from the jobcontroller log if it still fails.

Hi AnonimaKontonWTF, thanks so much for your help! Luckilly I've managed to get it working by deleting these folders (even though I've done that before with no luck). It seems I had to change the permissions first, then delete the folder structure. Now I've got all 3 additional instances working.

Thanks again and thanks to everybody reading these discussinos and helping out others! It's amazing.

I thought that was the problem, but that weird path made me think it would be easier to start from scratch. Harder to sort these things out without access.

The other day I did the same thing that AnonimaKontonWTF said in this post... I just trash the folder (saved the custom setting) works for me. To bad that Digital Rebellion 'Remove Compressor 4' app doesn't remove this folder.