State:New|TargetRelease:No Target|icon_bug|icon_nuke|database:public|Resolution:Fixed|BugID:432376|
Problem summary
Adding Burn-In Soft Effects (either one Burn-In track, or multiple Burn-Ins) across a long sequence can cause the memory usage to increase massively.
When Nuke Studio gets into this state, clearing the playback cache does not appear to significantly reduce the memory usage.
This issue appears to not happen if Timeline Disk Caching is disabled with the environment variable:
FN_DISABLE_TIMELINE_DISK_CACHE=1
Customer reported version
Nuke Studio 12.1v1
Customer reported platform
N/A
Steps to reproduce
1) Open Nuke Studio with a new project.
2) Import some QuickTime files. In this example 30 QuickTimes were used, and each clip was 5 minutes long (or 7200 frames at 24 fps):

3) Add a Burn-In to one of the clips (right click a clip > Effects > Burn-In).
4) Click and drag the Burn-In into it's own track, then stretch it across all clips on the Timeline.
6) Leave Nuke Studio idle and notice the memory usage increases:

7) If you clear the playback cache (cache > playback cache), you should also notice that the memory usage has not been significantly reduced:

Expected behaviour
The memory usage should be limited by the settings defined in the user's preferences.
Actual behaviour
The memory usage will continue to slowly climb, and it will use a significant amount of the system's available memory.
Workaround
This issue appears to not happen if Timeline Disk Caching is disabled with the environment variable:
FN_DISABLE_TIMELINE_DISK_CACHE=1 This may provide a viable workaround if you are not caching any frames to disk.
Reproduced by support
This bug has been reproduced in:
Nuke Studio 12.1v2 - Linux CentOS 7 - Windows 10 - macOS 10.13 (High Sierra)
Nuke Studio 11.0v1 - Linux CentOS 7 - Windows 10 - macOS 10.13 (High Sierra) - Regression
Unable to reproduce bug in:
Nuke Studio 10.5v8 - Linux CentOS 7 - Windows 10 - macOS 10.13 (High Sierra)
Earliest version tested
Nuke Studio 10.5v8
- This issue doesn't appear in this version and has regressed.
It appears that the issue may have been introduced when Timeline Disk Caching was implemented.
We're sorry to hear that
Please tell us why