View Full Version : backburner, dependencies or postRenderScript?

04 April 2009, 04:22 PM
Hi everyone!

I'm in a HUGE mess with dependencies in backburner, it has been a real pain to submit a serie of jobs with some of them dependent to others, but even with that working (I mean it! with the little "plus" icon and the jobs that correspond in the dependence list!:)), backburner starts dependent jobs without taking care of the status of the parent jobs, so even when they are still running, it launches them.
Soooo...I thought a lot... and I decided to use -postRenderScript command to run a script to resume jobs (initially submitted suspended for that purpose) at the end of their parent job...
I haven't found another solution to get control of the queue but using maxscript "netrender" interface (netmanager.connect, netmanager.getjobs(),etc.). And I can't find a way to connect to the manager other than with the netmanager.queryControl #wait command ( getControl() and queryControl #dontwait do not work)... but it exactly last 10 seconds to get the control and it seems to match exactly the time that a postRenderScript has to execute (I've tested some stuff, like filling a file with seconds indefinitely, and it stops systematically at 10) before backburner definitely kill it...
I don't know what to dooooo!!!
please, help!


04 April 2009, 08:30 PM
Welcome to BackBurner.

What Version of Max and BB are you using? And How many servers connected to the manager?

04 April 2009, 06:31 AM
it's the version delivered with max 2009, 2008.1 probably and we use just 8 servers actually...
Now that you say, I've never checked if there were a newer version or if they have corrected some stuff...

04 April 2009, 04:31 PM
I haven't got to 2008.1 yet, but I've seen BB 2k7 ignore dependencies too.

In the Python Thread I've some code to set dependencies which actually work.

But you have to install Python on you're user boxes and run the py via a doscommand.

Syntax for usage.
BBSetDependency <Ip Address> <Port> <Dependent Job Name> <Depends on Job Name> {<Depends on Job Name> ...}

04 April 2009, 06:21 PM
That seems to be awesome!!
I've just switched of production today so I won't have much time to work on my problem for the days coming but when I've got a little time I'm gonna dig in that TelNet stuff (excuse my ignorance, I didn't even know about this:) ) to work on an all new script...
Actually I haven't python installed on our network and since I already managed to set dependencies ( with a TCL script parsing and modifying an XML file from backburner :) ) and it did not work like I wanted, I'm gonna try to make something with a post render script, but with the telnet commands this time...or something like this, I don't know for the moment...
Thanks anyway! that's really nice of you to give such pieces of script,


04 April 2009, 07:32 PM
Yeah, you won't be able to directly set the dep's via Telnet, due to the full update command being some sort of binary transfer..

I found I had to command an Archive of the job via telnet, change the xml by having an open share on the \\network folder and then restore the job via telnet.

Good luck!

05 May 2009, 10:48 PM
OK, I've made my python script (highly inspirated by yours, i admit!) to resume jobs suspended in the render queue.
but I still have a major problem:
when I execute it in a post render script, with a DOSCommand(), or a ShellLaunch() for example, it starts, it tries to get the control of the queue (9 times on 10 somebody has a queue Monitor opened and locked on the network) so it keeps trying for the 10 HOLY seconds backburner asks to someone trying to get the control of the queue, and before it can do anything it gets KILLED by the BB server, which one only leaves 10 seconds (what a coincidence!!) to do anything before it decides the job is ended...

I really HATE working on Autodesk products, definitely...

CGTalk Moderation
05 May 2009, 10:48 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.