ID 476386 - FrameServerThreads does not correctly initiate the self.logger when rendering to the Frame server in Nuke 13 releases

Follow

Problem summary
When rendering to an external machine, it is possible to log the processes of each Frame server thread using the self.logger operation. This assists with helping debug any specific issues to sent threads.

It has been discovered that within Nuke 13 releases and later that the self.logger operation does not function as expected an brings up an error within the Frame server console.

Note: This does not occur within Nuke 12.2 releases and earlier.

Customer reported version
nuke.13.0v1

Customer reported platform
n_a_windows

Steps to reproduce

1) Within a new console/terminal window, follow the below instructions to create an external Frame server setup.
https://learn.foundry.com/nuke/content/comp_environment/rendering/render_farms_studio.html

2) When the external Frame server is setup correctly, launch a new Nuke 13 session, and cancel if prompted to cancel existing Frame server operations

3) Within this Nuke session, Read in a lengthy source file and render as an image sequence using the Frame server.

4) While the render is occurring, cancel the external Frame server operation in command prompt/terminal window (Ctrl+C in Windows)
Result: After potentially a few times cancelling and restarting the Frame server (by re-running the entered runframeserver.py operation) as the render continues in Nuke, the following message will appear



Expected behaviour
The self.logger operation should be logging the data and not appear as missing

Actual behaviour
The self.logger operation is not called and logging does not occur

Workaround
One potential workaround is the disable the self.logger operation itself by removing (or commenting out) the line of code within the runframeserver.py script
<nukeinstalldir>\pythonextensions\site-packages\foundry\frameserver\nuke\runframeserver.py

The code itself exists in line 219 as mentioned in the error:



Reproduced by support
This bug has been reproduced in:
Nuke 13.0v2 - Windows 10 - MacOS 10.15.6 - CentOS 7
Nuke 13.0v1 - Windows 10

Unable to reproduce bug in:
Nuke 12.2v6 - Windows 10 - MacOS 10.15.6 - CentOS 7

Earliest version tested
Nuke 12.2v6
- This issue doesn't appear in this version and has regressed

    We're sorry to hear that

    Please tell us why