Hi, this Compressor.app V4.x symptom is VERY VERY simple to fix and is due the residual state information maintained in the Qmaster cluster structures for the failed job(s). This information was not or cannot be cleaned up by the QMaster termination substasks error recovery nor job termination nor manually through intervention through the Compressor.app V4.1.x UI (compressor.appV4.1.x / preferences/advanced/ 'reset queue') mentioned by other posters. The latter, which, attempts to QUIESCE and subsequently remove this state information I mentioned earlier.
So before just going in and mindlessly blasting away the compressor.v4.1x and qmaster structures and parmlists and preferences or using 3rd part .app removers , this symptom and fix (workaround) deserves some explanation so that others who seems to have these experiences can understand and fix it themselves.
As I've mentioned many times on this and other forums, blasting away this state information can be very quite disruptive if you have other jobs and like us, other clusters we use in our workflow.
be mindful of templates, droplets, settings, definitions/templates, restart/redo history, other active jobs and agan of OBLITERATING the Compressor.app V4.1 x HISTORY that is EXTREMELY useful for a RESTART or REDO (see the completed paned in the UI)
Thus being selective and surgical (and smarter) helps to maintain job deadlines and won't upset colleagues. 😉
EXPLANATION Qmaster Cluster Job state Information in Compressor.app V4.1.x (post Dec 2013):
Information for ALL jobs that are QUEUED UP, ACTIVE (and stalled - waiting) or Completed (successfully or not) are maintained for each defined cluster (distributed or not). YOU may define many clusters and therefore any host (node or service nodes) MAC that is part of the distributed cluster will have these structures. In larger workplaces, obviously not all macs (hosts aka service nodes) belong to the same cluster in either or both of two places on each host (service node):
- your home directory) ~/Library/Application Support/Compressor/Storage/aaaaaaaaa-bbbbbbbb/ or xxxxxxxx-yyyyyyyyy etc etc
- and /Users/Shared/Library/Application Support/Compressor/Storage/aaaaaaaaa-bbbbbbbb/ or xxxxxxxx-yyyyyyyyy on the USUALLY however not always.host that is the cluster controller (where the cluster ws defined)
where aaaaaaaaa-bbbbbbbb or or xxxxxxxx-yyyyyyyyy represent a CLUSTER .. an example is:
/Users/Shared/Library/Application Support/Compressor/Storage/68ED8F60-8936DA51
The objects in these structures reveal active jobs, what's shared (distributed) and other information and some HIDDEN files. It's the hidden files. you need to clean up these little buggers as well. Here's an example ;
mavericks-server:~ warwick$ ls -1aR ~/Library/Application\ Support/Compressor/Storage/68ED8F60-8936DA51/jobs
.
..
.qmaster.plist <------------------
directory
history
requests
mavericks-server:~ warwick$
If you delete these objects, your compressor.app V4.1.x app and the Shared Monitor.app UI status will show nothing is active... which is what you have asked to do.
Residual from Compressor.app V4.1.x 'Active" and Shared Montor.app residual information.
Well ...if you look at the:
- system via Activity Monitor.app (filter compressord) or ps, top etc, you will see that it's highly likely that the compressord subtasks (depending on the instances you have started) are not active (idle) and nothing related to the Compressor batch for those jobs is actually running!
- You can also review the STOMP transcoder logs for each instance of compressor on each host in ~/librarylogs/compressor (or use Console.app). You'll note failures in there that are very easily seen... all is revealed
These two UI interfaces seem to retrieve this STATE information from the above.
SO.. here's what you might try. - delete some of these structure using the unix rm command. You may not have success using the Finder / trash because the empty of the trash may fail because these objects are enqued / serialised via the file system and wont be deleted until closed through normal or abnormal means or a restart. (again very disruptive). I recomend using the unix rm command. Step 1 is optional.
Simply on each host where this symptom exists (hosts = service nodes = comprise a cluster)
STEP 1: (OPTIONAL - for elegance and safety and disruption too only).. I don't do it .. your call.
In Compressor.app V4.1.x UI / preferences/ my computer/ "Allow other computers.... on my computer" - slide = OFF
Quit Compressor.app V4.1.x (shut it down)
STEP 2: use the osx finder to NAVIGATE to your home directory library (+shift+g) and enter ~/library/application support/compressor/storage
note the cluster directory there. for example: ls -a1 ~/Library/Application\ Support/Compressor/Storage/68ED8F60-8936DA51
.
..
.DS_Store
jobs
shared
mavericks-server:~ warwick$
delete these two folders "jobs" and "shared" and anything else and their contents in one go. Launch the terminal.app and enter the the text below in green (make sure there's no blanks and include the asterisk '*' on the end where xxxxxxxx-yyyyyyyyyy is the cluster folder(s) you see in this structure..:
rm -rf ~/Library/Application\ Support/Compressor/Storage/xxxxxxxx-yyyyyyyy/* and press enter...
optionally repeat as above for other clusters. While your there remove any dead cluster storage directories (check the dates..)
STEP 3: use the finder to NAVIGATE to the SHARED home directory library (+shift+g) and enter /users/shared/library/application support/compressor/storage. There may be nothing there is this a host/ service node. To avoid further verbosity......
STEP 4: (Optional as a result of Step 1 only if you did it...) on each host in the cluster, launch/start Compressor.app V4.1.x and
- reinstate the cluster sharing
- check you clusters in preferences/shared computers
- check all the SHARED/MOUNTED file systems on each hosts that they are correctly mounted, available, accessible and authorised!
Summary:
- Although this procedure appears quite verbose and complex, it is not.
- Knowing what to surgically remove and WHY is important in knowing how to maintain the transcoding system and make it stable and reliable and at utmost, USABLE.
- Thus, there no need to mindlessly BLAST away 😠 the compressor.app V4.1.a app structure (its setting/parms etc) and nor disrupt others, work in progress in the process as well as yourself.
HTH
Post your results for others to see.
Warwick
Hong Kong