Hi Deadline team,

we’re having issues with the Nuke scripts we’re submitting through Deadline. The jobs were all throwing errors and not rendering one single frame. After a bit of research i found that apparently the string in the Write node’s file path knob was different in the local version on the slave compared to the one that was originally submitted. Instead of “[…].%07d.jpg” the file knob’s value was “[…].%0/7d.jpg” (forward slash added between the “0” and “7”). As a first workaround we tried to submit the job with the option “Submit Nuke Script File With Job” unchecked. To our surprise the script file was still copied to the slaves locally and failed again. So maybe there are two bugs here?
The second workaround was to manually change the file know string to use the ‘####’ notation instead of the ‘%0Xd’ one for the frame padding. Unfortunately, this would require some additional work to be replaced in our pipeline scripts. So seeing this fixed would definitely be the preferred solution for us

cheers,
Holger

p.s.: this is with Deadline 7.0.0.33. Just realised there’s a newer build which i’m going to install as soon as there’s a minute or two available to upgrade.

UPDATE:
after investigating a bit more i realised that the Write nodes we generate contain TCL expressions. Is this maybe the cause of the issue as Deadline does some string replacement with the brackets of the expressions?
I attached a zip file containing the different copies of the Nuke script. It actually looks like the error sneaks in when Deadline copies the script into the local “threaX…” subfolders as all the other scripts are fine.
Inside the zip are four copies of the script. The original script (…_ORIGINAL.nk), the one from the Deadline repository (…_REPO.nk), the one from the folder on the slave called “…\jobsData[jobID]” (…_SLAVE.nk) and the one from one of the thread subfolders (…_SLAVE-THREAD.nk).
Hope this will help you finding the issue.

best,
Holger
nuke_scripts.zip (12.3 KB)

Hi Holger,

The reason the Nuke file still gets copied locally with “Submit Nuke Script File With Job” unchecked is because the Nuke plugin has Path Mapping enabled. When this is enabled, we go through the Nuke file and swap out paths from one OS for paths from another (if you have Path Mapping entries defined in your Repository Options). We need to create a local copy so that we don’t overwrite the original Nuke file.1

The reason why the issue is happing is because of the ‘’ in the TCL expression:

wmp_wav_001_050_comp_v001_an.%0\[value RenderNode1.fn_padding]d.jpg

The way our path mapping works is that we go through the Nuke file line by line, doing string replacements. Then, in order to avoid path separator issues in Nuke, we replace all ‘’ characters in a line that a match was found with ‘/’ , which is why you see that extra ‘/’ character show up. We think we can fix the issue you’re seeing by explicitly looking for occurrences of “[” in the lines and skipping them when replacing the path separators.

I’ve attached a modified Nuke plugin script that you can test to see if it fixes the issue. Just unzip the attached file to \your\repository\plugins\Nuke and overwrite the original Nuke.py file. Then submit a new job and let us know if the problem is fixed or not.

Thanks!
Ryan
Nuke.zip (5.29 KB)

hi Ryan,

thanks for the quick reply!
I just tested your modified Nuke.py plugin. Everything works fine now. I think it’d be great to include this fix in the Nuke plugin.
One suggestion regarding the “Submit Nuke Script File With Job” option: i totally understand that the path mapping overrides this option in the submission panel in Nuke.
It’d be great though if this option was disabled / greyed out when path mapping is active. This would make it more apparent to an artist that it actually does nothing in an environment that uses path mapping. Maybe you could also add a text in the tooltip help of this knob that explains it?

cheers,
Holger

Thanks for confirming that it works! We’ll be including this fix in beta 5.

We’ll also update the tooltip in the Nuke plugin configuration so that it says it can be turned off if no Path Mapping entries have been configured in the Repository Options. Unfortunately, we can’t disable the controls themselves because at this time, logic can’t be applied to these controls to control if they are enabled or disabled.

Cheers,
Ryan

Hi Ryan,

thanks for fixing this so quickly. I understand you cannot control the status of the knobs at the moment - consider this a feature request, though
Some additional text in the tooltip will definitely help to clarify this in the meantime.

cheers,
Holger