C4D - regex_errors "Project not found" Weirdness!

[AndyC]

So . . . All of a sudden and for no real reason we're now getting this:

ERROR:CmdRangeBackEnd: regex_errors found match: "Project not found"

The weirdest thing is that we are getting this error message on the 2nd or 3rd frame that the worker is rendering. So it's already running 1 or 2 frames and when it tries to pick up the 3rd job is when we seem to get the issues.

Was working last week - all of a sudden every job same problem!

If I re-submit frames once the job completes they will complete successfully and fail a % of the retried frames, retry those failed ones and they complete successfully and fail a % etc. etc. until they all complete!

Any ideas? Permissions are correct on storage (otherwise no frames would render at all), Path translation is set up correctly (otherwise no frames would render at all).

[AndyC]

Just to add some more confusion to everything . . . It's not just C4D!

COMMAND: "C:\Windows\system32\cmd.exe" /C ""C:\Program Files\Autodesk\Maya2013.5\bin\Render.exe" -s 780 -e 780 -b 1 -rd "Q:\testing\Maya\output" -renderer "mr" -autoRenderThreads  "Q:\testing\Maya\Dino_Test.ma""

Error: line 1: File not found: "Q:/testing/Maya/Dino_Test.ma"

Maya is doing it too!

[BrianK]

Hi Andy,

It's not surprising that Maya is doing it too.  This is not a problem with Qube or C4D or Maya... It's a problem with something else on your network. Something is causing access to the file server to be inconsistent.  It may be your AD/LDAP server (if you have one), it may be a failing/flooded switch, it may be the file server itself (maybe it has a limited number of allowable connections?  Maybe its disk is failing?  Maybe it doesn't have a good connection with AD/LDAP/NIS?).

I won't be able to help you solve the problem, but I can help you work around it.

In the submission dialog(s), towards the bottom, with "Expert Mode" turned on, there are two fields that are important:  "Retry Frame/Instance" and "Retry Work Delay". The former tells Qube how many times to try the frame before it gives up on it.  For example, setting it to 5 means "allow each frame to fail 5 times before moving on". 

The latter tells Qube how long to wait between each retry.  This field is *essential* in your case & was introduced to combat this very issue. As your testing has shown, this problem clears itself up eventually.  Without a delay between retries, Qube can blow through its retry attempts in a matter of a second or two.  Telling Qube to wait between retries gives the file server (or switch or AD server, etc) time to recover from its problem. 

You'll probably want to experiment with values for these fields. I would suggest 5 and 15, respectively, as a starting point.  YMMV.

I'm sure I don't need to tell you this, but so it's said, we are working *around* a problem, not fixing it.  You'll want to find out what's causing this behavior as it's likely not going to get better on its own.