State:Closed|icon_bug|icon_nuke|database:public|Resolution:Fixed|TargetRelease:12.0v1|BugID:181176|
"... guys were complaining about our network speed of reading files off a network in Nuke They found that using the addFilenameFilter to procedurally in python "shutil.copy" all read node in the current tree for the current frame on demand to Nuke's localization path and then rendering that frame of the tree was massively faster then just using Nuke with frames off the network with it's internal network copying operation. They were hoping to get a more formal way of implementing this then their current addFilenameFilter hack.
They said the current localization option in Nuke is too brute force and requires all frames referenced in each read node to be copied local. It blocks the gui thread while it copies. The timeline does this in a background thread which they wish Nuke did. Also it copies way more then they actually need...IE frames not in the current tree they are working on or stock footage from a read node with 5000 frames which they only need 100 of. Also they said our current localisation is too chatty and constantly checks to make sure ever read node is up to date every time they change any knob which from analyzing network traffic has quite a hit on their network.
This issue is only on windows machines (they are 100% windows).
Dev will be looking into this and provide some information on details about how to test network file reads for different image types (scanlines, tiles). The customer agreed to perform the tests and is currently waiting for a response.
We're sorry to hear that
Please tell us why