Support Portal

Planning for best render stability is an important matter, specially when you plan unatended renders all the night and so on. 

First we will comment the most common reasons for render problems, but wathever the reason for the stability issues please make sure to read the last point about HOW TO RENDER WITH MAXIMUM PERFORMANCE AND STABILITY. 

But first let's talk about the the most common reasons for crashes that you need to be aware:

CRASHES RELATED TO A PARTICULAR FILE FORMAT:

If the image format is suspicious then it should be tested isolated by removing all the effects. Just render the source clip to the render format. Then: 

- If a particular clip fails consistently to be rendered change the render format to confirm if it is the cause. If it is, please open a support case. Meanwhile, render to other format (uncompressed of at least less compressed) to be able to continue working.

- If the problem is related to the source format (not the render format) then check if other clips of the same camera work well, this is to discard that it is not an isolated camera clip that was corrupted in origin (which is certainly common). Otherwise please report the problem and attach a sample file.

CRASHES RELATED TO RAM AND GPU MEMORY USAGE.  WHEN THE RENDER BECOMES SLOWER AND SLOWER OVER THE TIME AND EVENTUALLY CRASHES, OR TAKES AN ABNORMALLY LONG TIME TO COMPLETE:

This is the most common cause both for "crashes" and for "never-ending" render times.

 The most typical sympthon is when the render works fine for shorter periods but fails with longer content (although not neccesarily).

To confirm if you are in this case, open the system monitoring tools while rendering:

- Linux: Open Edit->Extras->SystemMonitor, and also Edit->Extras->NVIDIA settings->GPU memory usage

- Windows: Open Task Manager and select the "Performance" menu, and watch RAM usage and GPU memory usage.

- Mac: Open the Activity Monitor and check for similar settings

Then start the render while watching the usage values in the above tools:

- If the RAM usage curve goes to abnormally high values over the time:

* If it does so in almost vertical fashion or discrete steps (staircase style) then it probably means that your scene is too complex for the available RAM

* If it does so in smooth diagonal fashion then it probably means a memory leak / software bug (in that case please contact support)

- If the RAM usage looks ok but the GPU memory usage is what goes over 90% (and please note that here we are talking about the GPU "memory", not the GPU "activity") then you are exceding the limits of your GPU.  But if it only happens sometimes then the techiques described at the end can still help to solve this (same about RAM).

SYSTEM CRASHES (WHEN NOT ONLY MISTIKA APPLICATION CRASHES BUT ALSO THE COMPLETE SYSTEM)

This applies to systems that suddenly power off in the middle of a render, reset themselves, become "frozen" with not even the pointer moving,  operating system crashes, and in general anything that requires a power cycle . The most common causes are:

- GPU driver issues (always check that you are using the latest GPU drivers)

- Thermal problems: Normally they do not appear inmediately after a cold power cycle but when rendering after a short while. Check CPU temperatures in the system monitor and GPU software.

- Insufficient PSU power: In principle they can produce similar behaviour to thermal problems and be easily confused with them (logically high power usage also means higher temperatures), but note that this type of problem is more inmediately linked to the sum of the GPU activity + GPU activity, it is not related to how long the system has been rendering at all.  Also it is much more consistent and easy to reproduce: Once you find an effect combination that crash the system it will tpically happen almosty instantanously, typically at the very moment you try to start rendering it (or even when you place the monitor bar on a complicated area). 

- Electrical issues:  These can be differences in electrical ground levels (between the computer and peripherals using different power plugs),  old UPS units decreasing their power delivery, and so on. A good test in these cases is to disconnect everything not strictily neccesary for the render and only use one power stripe for everything, using a unique wall plug.  

- Other hardware issues. The above are just the most common ones, but almost any faulty component or faulty cable can potentially produce this kind of behaviour, so better not to discard anything until finding the cause for sure. 

HOW TO RENDER WITH MAXIMUM PERFORMANCE AND STABILITY. 

This techiques will help in most of the above issues 

If you plan a long render unattended:

1 - Always activate the Render in split by segments mode (which does not create a long clip directly but one small render per clip) 

2 - use the Add to Render queue to create the render jobs (or the Write Script only).  

3 - Then exit from Mistika and let your render manager to do all the jobs (BatchManager in the case of linux, Smedge for Mac and Windows). This is because exiting from Mistika will free a lot of system resources that will then make the render processes faster and more stable.

4 - All this also applies If you need to deliver a single very long clip rather than independent clips:  In those cases you can simply add a last render job to create it as a simple transcoding job. Please note that you can add this job to the render queue as soon as the other render jobs have been created (by selecting their rnd clips as the source for the the new render job), so you do not need to wait for any partial render to complete. 

In this way you can go to sleep and your delivery files will also be ready in the morning, check the result and then delete the intermediate clips, so the extra space of the intermediate render is only used as temporal files during the render (alternatively, the whole workflow can be automated with Mistika Workflows...)

For doing all this we recommend to use the Mistika format as intermediate format. It is the fastest format,  it is full quality uncompressed (so no quality is lost compared with a direct render, as long as you select the same color sampling and bit depth), it is always well tested (it is the Mistika native format) and it reduces hardware resource usage very significantly compared with any other formats  (it barely needs any CPU and GPU resources, which also means less power and better thermals...).  

It may seem counter intuitive but this technique can in fact reduce the total render time even if there if the final render is made in two stages, because reading and writing the Mistika format comes almost for free in terms of render time (as long as the disk is fast enough, and nowadays they are), and because the encoding to the render format needs to be done anyway (so you are just delaying complex encoding to a final stage rather than doing it "per-frame"). 

This will also give more system resources to the render processes, and another advantage is that if one render fails (or a few of them) the render manager will still render the others and it can also attempt multiple retries, so your chances are much better. Finally, please note that render managers can also be paused, retried, re-prioritised,  send email alerts on problems, provide exhaustive logs, be scripted to automate more complex workflows...  

So if you plan intensive render it is really worth to dedicate some hours to learn and practice those tools, be sure that sooner or later you will get back that hours multiplied by 100...