AWS Thinkbox Discussion Forums

PreJob Script Behavior - Not as expected

I’ve got a pre-job script being added via an event based off of name of job.
I’m basically using an onJobSubmittedCallback to filter the job based on name.

making my changes to add the prejob script with job.PreJobScript = SCRIPTPATH.
I save that using RepositoryUtils.SaveJob(job)

I see the pre-job script appear in the job, but it does not get run. I see the event trigger, and the pre-job script get’s added, but does not run. I’ve tried submitting as suspended with same result.

**If I resubmit the job after the initial run both pre-job script and render work.

======

So I investigated further and found some people using RepositoryUtils.SetPreJobScript and when I use this I DO see appropriate behavior in terms of everything running. I see the event trigger, the script get’s injected in the job, and I see the script and render in the tasks pain. GREAT! But…

When I use this I"m getting a corrupted render status bar and some nasty deadline monitor console outputs about GUI. Okay I’ve done something out of order here?? I’m able to right click on the job and and fix the corrupted status of the job, the nice little informative window suggested that it is going to update the Tasks of the job from the Database.

What is the proper procedure to make this change so I’m not corrupting things?

Let me guess, are you doing this over an RCS?

I’ve seen this exact workflow and these same results from another customer. We fixed it in 10.1.4 but it might have come back up again.

To work around it we needed to use direct connection instead of the RCS. What version are you running?

Actually it’s just on a standard office renderfarm. Everything is just on network share via SMB.

We are however a few versions back on 10.0.25.2.

How is the machine that’s submitting the job connected? Direct connection as well?

That is, not using the web service or something? You may need to set this script into a different way, but I’m not certain what you’ve got already set up that’s failing.

Yes direct connect. It’s actually an event that grabs any matching job and adds the pre-job script to it.

Seems pretty straight forward but seems like the GUI is just pissed that it’s happening without it’s knowledge. LIke I need to update the database of that change?

I should explain why I asked, OnJobSubmitted event plugins run on whatever is submitting the job. So if the artist machine is connecting via RCS, or the job is getting submitted via the web service it’ll change where that script is firing.

But that’s not relevant here since it’s all on direct connection, so it’ll just be the regular old deadlinecommand running the event plugin.

By the sound of it this should be working, this probably is just a bug in how the job is getting updated by setting the pre-job script.

Unless you’re able to upgrade you’re going to have to find another way to set that script. For the other customer I mentioned we re-submitted the job from a non-RCS connection and deleted the artist-created job. You might want to do the same thing as you mentioned re-submitting the job works.

Our workflow was setting a “fixme” tag in the job’s properties and submitting it as suspended. Then another OnJobSubmitted event plugin would resubmit the job without the “fixme” tag. Just be sure that the event plugins are in the right order under Configure Events, as they’re fired top to bottom.

It’s a little janky, but it did work. You’re a little different but I bet it’ll work.

Let me know what you try, I’m sure we can get this working.

Okay so I ended up adding the prejob script in via the submitting application. All is at least showing up and not getting corrupted.

I seem to be unable to split my tasks though when I have the pre-job script enabled on the job. Seems like the concurrent task flag is not being respected when the pre-job script is enabled. I can submit without and I get my proper # of concurrent tasks.

Perhaps this is why the create and kill job suggestion earlier??:). You’ve been down this road many times:)

Oh that’s a fun new facet. I’ll be quick to admit, the create and kill trick worked and I wasn’t really going to ask too many questions.

I’d triple check your job submission however. The bug with the job scripts comes down to the task counts that make up the job not being summed up correctly. That’s why the Monitor console was complaining about the GUI as it’s being asked to draw a progress bar for -10/0 tasks. I wouldn’t think the concurrent task option would be a part of that as that’s just a flag that lets the Worker keep grabbing tasks from the same job till it hits the limit.

You know, we had jobs that didn’t look corrupted till we suspended->resumed them. I’d try that as well in case there’s still something amiss.

Privacy | Site terms | Cookie preferences