If you’ve upgraded to Nuke 9.0 or even Nuke Studio, like I did, recently, you might’ve bumped into some licensing and boot-up issues with Nuke. So, allow me to share my experience with this upgrade.
First off, Nuke 9.0 is just fabulous. I’m really in love with the software, even though there are a few issues I’m having from time to time. So, after upgrading to NukeX and Nuke Studio 9.0 I also had to update my licenses and with that, the license server. I’m not sure whether The Foundry completely abandoned the FLEXlm license server, or not, but I transferred all my licenses to the newer RLM licensing scheme. With that came a few issues. The most notable one was that Nuke simply did not start up. Easy fix:
- Stop the foundry FLEXlm server
- Uninstall any older FLT software, completely, delete your old licenses, especially from the C:\ProgramData\The Foundry\RLM and C:\Program Files\The Foundry\RLM locations on your license server
- Install the latest version of the FLT software
- Run the FLT tool and drag-drop the newest license in there. It should install automatically for you.
- Restart the RLM server
Now this worked. Nuke started booting up, but it took terribly, terribly long. I mean, Nuke 8.xx took about 2-3 seconds to check for the license on my server (via VPN) and boot up. Nuke 9.0v1 took over 20 seconds (!!!) to check for the license and even longer (!!!) for Nuke Studio to fire up.
Something was wrong and I wasn’t sure what. All I suspected was that my setup was acting up as I’m sure The Foundry would’ve done something about this if it were a bug.
And sure enough! I found the issue.
If you’re like me, a geeky TD that loves total control over his software tools , you are probably setting Nuke up via Environment Variables. I went further ahead and due to various reasons for keeping several versions of Nuke installed on my system and ready for usage, I created start scripts that setup the Environment Variables in a local scope of the application on start. Among those there were Environment Variables for setting up paths to the license servers, etc.
I’ve had this setup for years and it has worked without problems. I use this approach for all my programs I use in my workflow. It’s much easier to migrate settings and synchronize plugin versions, etc…, across the entire studio. I highly recommend you this approach. Anyways, the problem with something working for years is that once it behaves badly you have no clue why. This was the case. Nuke was taking way too long to boot up for it to be comfortable or seamless and it made me mad during the day. So I sat down and troubleshot.
There it was, I was still trying to contact the FLEXlm server even though it was down, so there was, probalby, some kind of a timeout setup (beside the one in my script) on the server before it jumped onto the RLM server. So, if Nuke is booting up very slow on you and you had it setup similarly like I did, try disabling the FLEXlm license path in your Environment Variables and see if it helps out. It sure did help me and NukeX 9.0 starts as fast as the previous versions did.
Hope this helps you as well.