I am in a bit of a confusion here:
I’m running Deadline 5.1
We have a server which renders all Nuke, Maya, Softimage etc files and our Client- server is Windows. My main concern is with Nuke and its plugins. I have made some additional plugins / gizmos /python scripts which all the artists can use, which are also stored in a centralized location. Every artist has added a NUKE_PATH environment variable to pick up the plugins, and this works fine on all machines also the server. The turning point is when I try to render my nuke file which has the additional plugins via deadline. It gives me an error that it can read the plugin and / or the nuke file is corrupt.
To double check things I opened the file in one of the boxes that spits out the error and rendered it locally. It worked just fine. So here I am confused as to what is happening. Is Deadline not listening to the env variable or is it timing it out or the env variable is or supposed to be setup in a different way.
I’ll buy you beer if you figure this out for me 
Have you restarted nodes since setting the NUKE_PATH environment variable? My initial guess is that Deadline was running at the time that environment variable was set, so it hasn’t recognized the change yet. Restarting the machines ensures everything is refreshed. If you haven’t done so already, give this a try and let us know if it helps.
Cheers,
I managed to narrow it down to the plugins which I made or installed are not being picked up by the farm correctly. Only a few of them get rendered. Here again, if I open the same comp on that particular box, it gets rendered without any errors.
To answer your question, the farm has been restarted after the new variable has been added.
Are you by chance using OFX plugins? If so, nuke handles plugins with the OFX_PLUGIN_PATH variable rather than the NUKE_PATH variable, set another variable to point to your centralised plugin folder, logout or restart the nodes and it should pick them up.
Oh, and also make sure you set them as system rather than user variables!
The variable is setup to system. So I did a new test:
I specified one single machine (a workstation rather) in a pool and assigned my file to render on that machine. Here the variable is set for the whole system and its running the correct version of Nuke (same version that I am using).
The errors I get are only from the few specified plugins. Say I have 10 plugins, 5 of them error out.
Now I open my file on that machine and render it locally and boom it works just fine.
Thanks Russell and Elliott, but I am not using any OFX plugins just simple nuke gizmos to be more precise.
Errr, are any any of them licensed plugins? Maybe check the permissions?
Can you render the script using the command line?
Dont need a license - they are free. No permission errors and it renders with command line.
Err is my original thought haha. I have gone blank with this problem o.O
Here’s something to try. First, install Process Explorer on the workstation you were using for your recent test:
technet.microsoft.com/en-us/sysi … 96653.aspx
Run it, then right-click on the deadlineslave.exe process and select Properties. Then look under the Environment tab to see if the NUKE_PATH variable is defined, and if it’s set to what you expect it to be. At the very least, this will confirm whether or not the Slave is seeing the variable, and allow us to focus on other possibilities.
Thanks!
Does the render still fail (when submitted through deadline) if all those plugins are moved locally? Maybe temporarily delete the variable whilst they are installed locally just to be sure they are referencing them locally.
Could it be server related? What server OS are you on?
Clutching at straws now…
Russell, I downloaded the Process Explorer and it is indeed using the Env Variable that I want it to use. Atleast I am slightly satisfied that its not the variable anymore. It has to do something the way deadline taking the job in its pockets and assigning to the boxes on the farm.
Elliot, I did another test where I deleted 3 versions of nuke and kept a stable one. Funny as it sounds. The boxes rendered it smoothly without errors. I might have to do another test once again. Will keep you posted as to what is happening.
As for your question Its a windows server.
Thanks for your time and help guys.
Are you rendering locally and on the node using exactly the same version of Nuke?
Are your Deadline Nuke jobs executing a different version of Nuke on your nodes than the version you test manually?
Ie: Do you have more than 1 version of Nuke installed?
I think that I am getting somewhere, the multiple versions of Nuke is disturbing the flow of the renders. It might sound weird but does it even make a difference if the machine or node have multiple versions of nuke on it?
It does, if a newer version of Nuke tries to utilise the locally cached version of OFX / script plugins which were originally cached in an older version of Nuke.
You can test this, by manually forcing a deletion of the local Nuke cache where ever it may be stored on your render node and then testing again.
Generally speaking, its best industry practice to render and comp a project all through the same version’s of software for the duration of a project. I would ensure you always comp locally and render remotely via Deadline in ALL the same version of Nuke.
I think I am very close. To keep you guys posted, you guys were right about restarting the proc, checking the system env variable and multiple software clash. I tested it on workstations, it works fine now. I tested it on a single node on the server and it works fine as well. 
Tomorrow, I am going to implement the same thing on all nodes on the farm. Hopefully it should be smooth.
This worked smoothly! If you guys are in Soho. Give me a shout - I owe you a beer 