From: Mat X <info@matx.ca>
Subject: Nuke GenArts Sapphire renders failing
   Date: Mon, 07 Feb 2011 22:53:30 -0800

For the long story version read on....

What I tried:

I reinstalled Sapphire.

	- seemed to work, but would start failing again soon enough

I copied the Sapphire plugin bundle into the Nuke built-in plugins folder

	- seemed to work, but would start failing again soon enough

	- seemed to work, but would start failing again soon enough

Hey Greg

For the last couple of years I've been using Rush to create standardised production QuickTimes from rendered frames, email the relevant groups, publish frames, move data around the network etc and it's been working really well overall, but I'm getting a reoccurring problem with the initial render where it's immediately moving to state "Done" without the render ever happening, when I click "Que" the job will then render properly without complaint.

As the time elapsed on these problem jobs shows as 00:00:00 I thought there might be a way of saying if job < 00:00:01 then ReQueue?

Regards

Craig

Craig Allison
Digital Systems & I/O Manager
The Senate Visual Effects
Twickenham Film Studios
St. Margarets
Middlesex
TW1 2AW

+44208 607 8866
craigallison@(email surpressed)
skype: craig_9000

Craig Allison wrote:
> For the last couple of years I've been using Rush to create standardised =
> production QuickTimes from rendered frames, email the relevant groups, =
> publish frames, move data around the network etc and it's been working =
> really well overall, but I'm getting a reoccurring problem with the =
> initial render where it's immediately moving to state "Done" without the =
> render ever happening, when I click "Que" the job will then render =
> properly without complaint.

	Hmm, can you include some more info.. when this happens, paste me:

		1) The 'Frames' report for the first time it says 'Done' (but no render).
		   I'd like to see what machine it picked up on where it quickly became "done".

		1a) Is a frame log generated for that frame? If so, paste that here too.

		2) The 'Jobs Full' report for this job.

		3) The script that submits the job, and the script (if separate) that renders it.

		   It's possible the script is submitting the job in such a way
		   that the frame is forced to start in the 'Done' state on submit.
		   (It is possible to do this)

		4) The rushd.log from the machine that took the render the first time
		   (where the render time is 00:00:00)

> As the time elapsed on these problem jobs shows as 00:00:00 I thought =
> there might be a way of saying if job < 00:00:01 then ReQueue?

	You could make a done command that checks this and requeues it,
	but before you try covering up the problem, let's first try to
	determine the cause.

-- 
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)

Craig has followed up with me offline on this; seems it might just be
a small omission in script he's working with.

The script writes out a shake file then submits a shake job to render it.

The problem just might be an issue of a missing close() in the script;
after writing the shake file it submits the job. But without the close(),
if the job picks up quickly, shake will see an empty file, and finishes
immediately with the frame "Done".

The intermittent behavior seems due to how quickly the job picks up;
if it picks up quickly, shake sees an empty file. But if it takes
an extra second or two to pick up, the submit script finishes executing,
automatically closing the file, flushing it to disk.. then when the job
kicks in, shake reads the proper file.

This would also explain why re-que'ing the frame always renders successfully.

Adding a close() to the custom script will likely fix the problem.
Otherwise, if there's still trouble, I'd suggest experimenting with sync(1)
and/or fsync(2) to ensure the OS commits the file to the remote server before
continuing. (But that really shouldn't be necessary.)

I can confirm that the close () command has fixed the issue, haven't had a problem since.

Awesome work once again Greg!

Thank you

Craig


Craig Allison
Digital Systems & I/O Manager
The Senate Visual Effects
Twickenham Film Studios
St. Margarets
Middlesex
TW1 2AW

+44208 607 8866
craigallison@(email surpressed)
skype: craig_9000




On 17 Feb 2011, at 20:33, Greg Ercolano wrote:

> [posted to rush.general]
> 
> Craig has followed up with me offline on this; seems it might just be
> a small omission in script he's working with.
> 
> The script writes out a shake file then submits a shake job to render it.
> 
> The problem just might be an issue of a missing close() in the script;
> after writing the shake file it submits the job. But without the close(),
> if the job picks up quickly, shake will see an empty file, and finishes
> immediately with the frame "Done".
> 
> The intermittent behavior seems due to how quickly the job picks up;
> if it picks up quickly, shake sees an empty file. But if it takes
> an extra second or two to pick up, the submit script finishes executing,
> automatically closing the file, flushing it to disk.. then when the job
> kicks in, shake reads the proper file.
> 
> This would also explain why re-que'ing the frame always renders successfully.
> 
> Adding a close() to the custom script will likely fix the problem.
> Otherwise, if there's still trouble, I'd suggest experimenting with sync(1)
> and/or fsync(2) to ensure the OS commits the file to the remote server before
> continuing. (But that really shouldn't be necessary.)
>