I received an email that said my job was done, but the output folder only has some of the frames?
There are multiple possible causes of this. In no particular order:
- This may be due to the output folder you defined when you submitted the job being on a virtual drive like Dropbox, Google Drive, or similar. Virtual drive software prohibits your operating system from really knowing when file operations complete, so your operating system can respond to our agent saying that files have been written when they have not. Use UNC or local folders as output folders for your jobs. Local folders are the most reliable of the two, since UNC paths may or may not be accessible when the agent is trying to write to them. After all the frames have been delivered, you are certainly free to move them wherever you wish.
- Output files were moved/deleted after they were delivered to your machine. As obvious as this reason is, there have been many customers who accidentally moved files around while compositing early results. Once our agent receives a response from your operating system that it successfully wrote the frame to the output folder, all of our copies are immediately purged from our system.
- If you use Cinema 4D, check to make sure the frame rate settings in your project match the frame rate settings in your render output options. If they do not, there won’t be a direct correlation to the frame numbers that C4D writes when asked to render all frames from x to y.
So you understand how our system works internally to prevent this situation, render applications are watched to see that they exit with no error code (0x0 exit code) and have written a/an output file(s) to the folder we instructed. If any completed frames wrote no output files to the output folder, but the render app exited with an 0x0, then our system sends a “no output” warning email to you and us while it suspends the job. Any currently rendering frames are allowed to continue, in hopes they will produce the output that is expected. Jobs in this state usually require human intervention to assess the nature of the problem.
If a render job has output at least some files as expected, but some frames in the job produced no output, then the frames that produced no output are automatically re-queued to render again. This is done by our system only once when all frames have reported as complete. Only the frames that did not produce output are re-queued. Cost for those frames is reset to $0. If, after our system tries to render those frames a second time, there are still no output files, our system sends the same “no output” warning email to both you and us while the job is suspended.
We have made and continue to make every effort to have our system correctly handle these situations automatically, but poorly-written render applications prevent that. Examples of such poorly-written applications are After Effects, which exits with an 0x0 no matter what happens during a render attempt. Another such example is the Renderman engine in Maya, which likes to exit with an 0x0 when it senses licensing problems. Please understand that any application, render engine, or plug-in that incorrectly returns an 0x0 exit code to our system when there was actually something wrong is misleading to you, us, and everyone using that software. It is not within our realm of responsibility or capability to correct such problems.