return job id with in-app after effects script

[ajk48n]

I'm trying to find out the job id for a job submitted with the in-app script in after effects. I basically have 2 comps in after effects, and I need the second one to wait for the first one to finish before it starts.

So I was going to use the job id of the first as a dependency of the second, but can't seem to get the job id to be returned in after effects.

Does anyone know a way to find this out?

Thanks,
Adam

[BrianK]

Hmm... the current in-app submission for AE runs via a system call that starts a Qube GUI with many of the parameters pre-populated.  The return of that call is very verbose - fetching a job number out of it would be difficult.

In order to get the job id in AE, I believe you'd have to write your own submission script for AE (you can use the one that is provided by PipelineFX as a guide - it lives in AE's scripts directory).  In your version, rather than calling:

Code: [Select]

/Applications/pfx/qube/qube.app/Contents/MacOS/qube --submitDict "{'prototype':'cmdrange', 'name':'AEtest Comp 1','package':{'simpleCmdType':'aftereffects (aerender)','Project_path':'/Users/briank/pfx/demos/AfterEffects_text.aep','Output_file_path':'/output/output.[#####].jpg','All_comp_names':'Comp 1','-rqindex':'1','range':'0-300',}}"
(which is what is happening now)

You'd call something like

Code: [Select]

qbsub --range 1-300 --chunk 30 --name 'AEtest Comp 1' '"/Applications/Adobe After Effects CS5/aerender" -project "/Users/briank/pfx/demos/AfterEffects_text.aep" -s QB_FRAME_START -e QB_FRAME_END -i QB_FRAME_STEP -output "/output/output.[#####].jpg" -rqindex 1'
With that, the return value of the system call is the job id.  So, for example, in some AE jsx file, this would give you the qube job id in an alert box:

Code: [Select]

var cmd = "/Applications/pfx/qube/bin/qbsub --range 1-300 --chunk 30 --name \'AEtest Comp1\' \'\"/Applications/Adobe After Effects CS5/aerender\" -project \"/Users/briank/pfx/demos/AfterEffects_text.aep\" -s QB_FRAME_START -e QB_FRAME_END -i QB_FRAME_STEP -output \"/output/output.[#####].jpg\" -rqindex 1\'";
var cmdOutput = system.callSystem(cmd);
alert(cmdOutput);

The drawback, of course, is that the user can't change any options unless you first populate some sort of a javascript dialog box with qube options then pass them through this style of submission.

[ajk48n]

ok, thanks.

I'll try that out. At the moment, I am parsing the qbjobs command to get the most recent job id, but this will be a much better way.

[ajk48n]

well, I've gotten that to work, but I have a side questions, although I'm not sure if it really matters at this point.

After submitting a job with the in-app gui, when I look in at the properties of the job with QubeGUI I see a lot of different variables under package, like cmdline, cmdTemplate, rangeExecution, etc.

When I submit the job with qbsub, the only line under package that shows up is cmdline. All the variable seem to be passing correctly, and the render looks like it's working, but I was wondering if the difference is going to matter at all?

Thanks,
Adam

[BrianK]

Many of those variables are there to populate the submission dialog with options.  At the end of the day, with AE submission at least, as long as the command line is correct, the rest of the job's package doesn't matter a whole heck of a lot.

You should pay attention to some parameters of qbsub...
--cpus determines the number of jobs slots this job should use across the farm ("subjob processes" from the GUI), so you probably want that to be larger than 1, or you job will only run on one computer.

--chunk determines the number of frames to be rendered by each agenda item.  Because AE frames are so short to render, the overhead of opening the app and loading the project is often heavier than the rendered frame itself.  Chunking tells AE to render a frame range at a time rather than a frame at a time.  A large chunk is good, but means that there's more to retry if something goes wrong.  Ideally, each chunk will have about 15 seconds of actual render time to prevent the supervisor from being overworked and prevent the chunks for being very large if they need to be re-run.

--reservations will allow you to set any number of reservations.  AE is a thread-hungry app - each instance can easily open 50 threads.  In practice, I've found that if you load up a machine with AE renders (say 16 instances on a 16 core machine), some part of AE gets confused and you'll see zombie processes being left behind.  After too many zombies are in your process tree, AE will stop running & will require either filling the PIDs by hand or rebooting the machine.  The way around this is to force a host.processors=1+ reservation (--reservation "host.processors=1+").  This tells qube that at least 1 processing unit must be available to start the agenda item (chunk), but each agenda item will occupy the entire machine.  In other words, no new work will be assigned to this node while this agenda item is running. YMMV.  Testing is key here.

Good luck!