ID 313627 - NukeAssist 11.0 always runs FrameServer process in the background so it requests a regular Nuke license (nuke_i) too

Follow

Problem summary
NukeAssist 11.0 always runs FrameServer process in the background so it checks our a nuke_i license too.

Customer reported version
nuke.11.0v2

Customer reported platform
Windows 10

Steps to reproduce

1) Have regular Nuke (nuke_i) and Nuke Assist (nukexassist_i) licenses available

2) Launch NukeAssist 11.0 and have an empty script.

3) Check your license usage and you will have both nukexassist_i and nuke_i licenses checked out.
It is easiest to see this with floating licenses and checking the status via the RLM Webserver.

Workaround
You can prevent Nuke Assist from running the background FrameServer process by using the --disable-nuke-frameserver command line argument.  i.e. launch NukeAssist with the following command

Nuke11.0 --nukeassist --disable-nuke-frameserver

Reproduced by support
NukeAssist 11.0v1 - Windows 7 - macOS 10.11.6 - Centos 6
NukeAssist 11.0v2 - Windows 7 - macOS 10.11.6 - Centos 6

Earliest version tested
NukeAssist 10.5v5
Nuke 11.0v1 introduced the FrameServer for regular versions of Nuke.  In earlier versions it only ran for NukeStudio sessions.

Expected behaviour
Running NukeAssist should only request and checkout a nukexassist_i license.

Actual behaviour
NukeAssist 11.0v1 and 11.0v2 always run a Frame Server process which always asks for a nuke_i license for the local render slaves.  Even if you set the Performance > Threads/Processes > "frame server processes to run" preference to 0 NukeAssist still runs a single FrameServer background process which requests a nuke_i.

If there are no available nuke_i licenses available and you have default settings to run multiple Frame Server processes then you may get a pop up warning the "The Frame Server has encountered an error" shortly after opening Nuke Assist.  The warning doesn't appear if you set "frame server processes to run" to 0 and the Frame Server process fails quietly in the background.




 

    We're sorry to hear that

    Please tell us why