Event Scripting Error Handling

Deadline
1

Hi All,

I’m scripting an event plugin that knits a compositing render process together via 3dsmax output, to nuke, to AFX. in the OnJobFinished handler, after the 3dsmax render job has completed, I am starting a custom python script to nuke via terminal mode to update the filename in the readnode in the nukescript before submitting it as a nuke job afterwards.

Only issue i am seeing is sometimes, for unknown reasons, the nuke exe has crashes (this seems to randomly happen from time to time, i.e cant hook up a license, etc etc) The offical reason is nuke process failed to exit after 0 milliseconds

if this happens, i’d like to be able to re-call the event as most likely it is fine second time around. I don’t really need to requeue the job as the render output is fine, just re-fire the event OnJobFinished handler if this condition occurs.

Any thoughts? can I just call something like

 self.OnJobFinished(job)

from with in the try/catch bracket? or do i have to use another handler. I’d like to get an idea of how to handle conditions within the plugin if im using commandline stuff that is important to the overall process

cheers,

Pete

2

Hey Pete,

As long as you’re not trying to generate an avi/movie type of output which of course can only be generated on 1 machine, I would consider building an event plugin which submits a fresh job into the queue, whether it be a custom/hybrid plugin or just a Nuke job which has a corresponding event plugin when it completes to submit the AFX job. (The former suggestion of a custom/hybrid plugin type simplifies this double-step). By submitting the processing as jobs back into the queue, you will get better scaling, visibility and redundancy. Let me explain. The event plugin will effectively get executed by 1 slave when the onJobFinished event is executed. Typically, it will get executed by the slave which completes rendering of the last frame of the job or by your own machine, if you were to mark the last frame as failed and then completed (BTW - this is a good way to test/debug when coding event plugins), so the event plugin will execute whatever py code you give it, but it will process on just 1 machine, which doesn’t scale, that 1 machine might have an issue pulling a Nuke license and that 1 machine might go pop for some reason and the onJobFinished event isn’t going to be fired again (well, not automatically anyway).

So, if you’ve got lots of frames to process, spawning a job back into the queue will scale nicely, be redundant like your other jobs in the queue and of course, be visible to users via monitor. Of course, by using the existing plugin architecture of the Nuke and AFX plugins, you get all the functionality/reliability of the existing plugin job types. Instead of hoping you have a Nuke license available at the exact moment you need your process to execute, you could do a find/replace RegEx on the nuke script as it’s just ASCII via python to insert, say the new file path into the Nuke read node. That would save you 1 hop and lower the risk of Nuke not running.

Have you considered using Draft in replacement for Nuke for the first part and then just submitting an AFX job. Maybe Draft could be used for both parts of the process (replace AFX as well)? Depends on what operations you need to do. Check out the Draft docs on the left of this link for various cook-book examples:

thinkboxsoftware.com/draft/

Mike

3

Hi Mike,

Thanks for your reply and I hope you are well.

The system I am writing is I think already doing what you are suggesting - I am spawning jobs from other jobs and tracking their IDs on submission in order to set off a comp file after everything is done. I’m pretty familiar with Draft, we already use it from comp to render slap comps and render checks but it’s not suitable for what I want to do here.

And it works apart from this occasional quirk with nuke terminal mode on the network. So it strikes me that thanks to your input, there are a couple of options:

Submitting a commandline job to fire the nuke terminal command and the python update script
Regexing the nuke script to update paths etc via a python job on deadline

While both have an element of error checking in terms of their position in the overall process, I would just as easily call it on submission from max and perform the process there and bypass Deadline altogether for this small part of the process. The nuke terminal script operation takes a fraction of a second and has never failed on my submission machine, so it feels a little overkill to submit a dedicated job just for the luxury of error logging.

Thanks again for your ideas

Pete

4

Hi Pete,
All is good. Thanks!

Sounds like you have it all in hand. I would just add as a thought, that the event plugin is effectively just a py script that gets executed, so you can carry out any RegEx’ing within this script with no need to submit a python job just to do this for you. Also, you could use this event py script to generate a Nuke script dynamically and then do the path swap-out for you. The event plugin returns the “job object” which will allow you access to all the job’s current properties.

This is how I made an event plugin to convert VRay tiled EXR’s -> scanline based EXR’s via generating a Nuke script within the py script and then submitting the job into the queue. (This was before Chaos starting shipping various cmd line tools).

Anyway, couple more ideas…all depends if it’s important to take the “submission” machine out of the equation here. Personally, I always tried to ensure Nuke licenses were never tied up as they are so expensive, it was best to have them available as much as possible to either the artists or main nuke render queue tasks :slight_smile: I can’t remember if the slightly revised Foundry licensing for those under Annual subs, allows the “Nuke Assist” lic’s to be used as well in terminal mode, thereby giving you a few more nk licenses…I digress anyway. :slight_smile:

Going back to the original cause of the issue, ie: Nuke licensing. IIRC, you can contact The Foundry and ask for any old Flexlm based license for Nuke to be upgraded to use the newer, replacement RLM license system. IIRC, the licensing is a little kinder for these kind of errors. Actually, just making sure you have a new’ish version of the Flexlm daemon, I know helps to make things like this more reliable as well - so that would be a possible route as well. Again, check with the Foundry on compatibility Flexlm version levels with Nuke.

If you do end up using Nuke, don’t forget that you could query the “limitgroups” for your Nuke license count, to ensure a license is potentially available, before proceeding, if this is causing the Nuke process to flop over.

Finally, you might be interested in the new v6.1 RESTful standalone py API coming as well, as this would allow potentially another route for pipeline integration in the future.

Mike