Closed unfa closed 6 years ago
Would you share that project with me?This is obviously a deadlock somewhere.Things to try:- if the rod of the input to the write node is very large, put a crop before the write (not necessary with 2.3.10)- reduce the number of threads used to render.
Did you get time to test with 2.3.10? Did you take a look at Natron memory usage? Use any process information display / top / htop. Did you try limiting the cache size in the parameters? Did you try limiting the number of rendering threads to 1 in the parameters (yes, I know this is not a solution, but it helps cornering down the problem)?
Do you have the possibility to send me your project, so that I can take a look at it? Send me a link by email.
@unfa any feedback?
Yes, sorry for my latency. I can deliver the project file - no problem. I'm not sure if it's reproducible without the used input image sequences (which are huge). I'll post the project file here soon.
This issue was moved to NatronGitHub/Natron#248
please add new comments to https://github.com/NatronGitHub/Natron/issues/248
Problem
I worked on an animated audio visualiser for my music album. I had to render out 2400 frames of a looped sequence that I could use later in another Natron project to produce the final comp.
However I was able to only render 50-70 frames at once each time. After that the rendering would stall. The CPU usage would drop to near-zero. I tried both from GUI and using NatronRenderer CLI - same behaviour. I tried different Natron versions: 2.3.5, 2.3.8, 2.3.9 - same problems. I yet have to try with Natron 2.3.10.
It also brought my whole system down multiple times - that might be a SWAP issue that I have (I've moved my system to ZFS and since then I had system freezes when SWAP is being used) - probably unrelated to Natron.
After a few days of trying different stuff I've decided to resign from using Natron for this production, because if I have to manually restart rendering for 100 000 frames that I'm going to need - it's just not worth it. Also the system freezes made it not look good if I had to have the system render non-stop for a week for example, mostly unattended.
Now I'm rendering this project with Blender.
I managed to render out the 2400 frames of a looped sequence in one go by rendering only a small subset of my initial project - so I guess some part of that node graph causes a problem.
I had some warnings about NaNs converted to white in a Crop node, but I don't think this is a reason why the whole thing stops rendering after a while.
Is saves out proper frames, it looks like Natron is stopping to start new rendering processes, and it just lets the current ones to run and finish properly, but then it "forgets" to render more frames.
I first thought that maybe the problem is a SlitScan node - but this one worked well. I wonder how can I debug this issue to find out what could have caused the stalled rendering.
Expected behavior:
Rendering all frames in the range.
Actual behavior:
Rendered a couple of dozens of frames, then it just stops - no crash, no error messages, no smoke.
Steps to Reproduce
I can host my project but it requires lots of data to run, not sure if I can reproduce the issue without that.
Versions
Multiple versions of Natron before the 2.3.10 release.
Linux Mint 18.3 KDE5, linux-lowlatency-hwe kernel. Ryzen 7 1700 CPU.