OTOY Forums

I get this error randomly (from what I am observing)

It seems to happen more when using the Que to launch renders. Sometimes the render will go anywhere from 1-150 before I get the error.

This is a huge headache since I usually Que renders to go overnight just to come in the morning and see that they have failed.

Anyone have this issue or know what might be going on?

I can say confidently that this problem did not start until the 2.11 updates.

I am working over fibre to a project server that holds all scene data and assets. The render results are being written to the same network drive.

Thanks for anyhelp!

can you show me screen capture of error? Are you on windows? Is it a disconnection from network server?

I am in an OSX environment.
It does not appear to be a disconnection. I can also replicate this issue on a workmates computer with similar specs.

Since I am using the Que fuction I do not get an on screen error message but I will attach the render log
This is what the error looks like in the Que though

Is it occurs only with textures which are over a network? Can we do a few tests?

I will try a render with all all textures local and save the results local as well to see if that helps the problem.
I will report back

Thanks.
For first test, I want to see console output. Let's check output.

Second test with debug mode.
If you put this file to same place C4D's application, it will produce a detailed log output file. Let's check the "octane_log.txt" file.
Don't forget to remove two files after test completed. If will slow down the everythings if you forget.

Update:

I rendered lots of frames overnight using C4D Que and saved to my local HD with no write errors...
Maybe this narrows down what the problem could be.

When I have time I will run the files that were "erroring out" again and send you the console output.

Try to set compression in rendersettings->octane from "RLE" to "none".

This should do the trick.

Maybe otoy / maxon can fix this bug in a later version, so that render runs stable under RLE as well.