Daniel Browne wrote:
> I'm sure Dan Rosen's inquired about this before, but has anyone found a resolution
> to the issue of the nuke frame log not updating until the render is
> complete? I believe you indicated to him that this was an issue with STDOUT
> output buffering which was internal to Nuke.
It sounds likely.
Try running the command line of nuke from a shell prompt,
and redirect the output to a file, eg:
nuke -arg1 -arg2 .. > file.out 2>&1
..and while that is running, open another window, and try to look
at the contents of the file.out file, eg:
UNIX: tail -f file.out
WINDOWS: type file.out
If you don't see any output until the render is done or close to done,
yes, that is the problem.
If you /do/ see the output (eg. if file.out is on a local drive),
then it might be a problem with the file server.
If you think it's the file server, then try the same thing,
but:
1) do the test on a render node
2) redirect the output to a file /on the file server/, eg:
nuke -arg1 -arg2 .. > //yourserver/somedir/file.out 2>&1
and then, instead of opening another shell on the same render node,
open a shell on a workstation (or some *other* render node)
and try to inspect the file, eg:
UNIX: tail -f /yourserver/somedir/file.out
WINDOWS: type \\yourserver\somedir\file.out
If you only see the 'delayed output' problem that way, then it's
possible this can be corrected, as likely the issue you have is:
1) Your render nodes windows
2) Your file server is unix running samba
3) You have "oplocks" enabled in your samba config
If that's the case, turning oplocks off in your smb.conf file
for the volume may solve it. This disables client side caching
that can cause write buffering to happen at the render node
when it shouldn't, because samba has some long standing compatibility
bug with window's client side file caching.
If so, this issue is covered somewhat here:
http://seriss.com/cgi-bin/rush/newsgroup-threaded.cgi?-viewthread+801+802+803+805+807+808+810
I've seen this problem many times over the last 10 years,
and in this particular case, has nothing to do with the
renderer in question.
However, if that's not it, then yes, it might very well be
stdout buffering in nuke, and you /might/ be able to fix it
yourself if you can use the correct python or tcl calls to
disable stdout buffering on nuke start-up. In python, there
are apparently several ways to disable output buffering:
http://stackoverflow.com/questions/107705/python-output-buffering
..which mentions:
1. Use the python "-u" command line switch
2. Wrap sys.stdout in an object that flushes after every write
3. Set PYTHONUNBUFFERED env var
4. sys.stdout = os.fdopen(sys.stdout.fileno(), 'w', 0)
I'd say in your case option 4 might work.
You might also ask the Nuke folks about this; assuming you
can replicate the first case above (eg. redirecting to a /local/
file and getting delayed buffered output), then ask the nuke dudes
about disabling output buffering, citing that test case.
But /don't/ bother the Nuke folks if you have the samba issue
above (second case), as that's nothing to do with nuke, and
everything to do with the file server's own config.
--
Greg Ercolano, erco@(email surpressed)
Seriss Corporation
Rush Render Queue, http://seriss.com/rush/
Tel: (Tel# suppressed)ext.23
Fax: (Tel# suppressed)
Cel: (Tel# suppressed)
|