<div dir="ltr"><div class="gmail_default" style="font-size:small"><font size="4">Problem Solved and some final feedback:</font><br><br>Memory leak fix has been checked into GIT. The problem started Dec. 27 so the AppImages created on Dec. 31 will have the problem but not very many users update theirs on a monthly basis.<br><br><b>All </b>- the Cinelerra program code is really quite complicated so problems like this happen.  It will never be bug-free or easy to modify, but still we need to attempt changes to move forward.<br><br><b>Stefan</b> - thanks so very much for reporting this issue and your persistence in working on it.  It is a BIG help when users do their own builds because we detect problems earlier that way. Initially my first attempt at creating the problem opening new viewers did not create the memory leak, apparently because the video contained no audio (so that was a bad test on my part). The EDL undo problem does not crash for me, but even crashing on other systems is not nice.  To test on the current GIT:<br>  1) Load a jpg image, it will expand itself as default 3 sec long timeline.<br>  2) "Save as" with xml extension.<br>  3) Load this xml as nested.<br>  4) Hit 'undo' right away.<br>For Andrew, it crashes.<br><br><b>Rob</b> - you brought up a lot of good questions to investigate which I will keep in mind going forward.  Especially something to keep in mind is to "transcode your content directly, independently of cinelerra" - this can make the input more palatable to Cinelerra.<br><br><b>Georgy</b> - after reading your email about "some frames with very special properties", I downloaded a video sample and ran "strings" on it (because that is about all I knew to do) and certainly found a bunch of weird stuff after the initial attributes and before the actual data. And sections between as well as on the end.  It must be some kind of filler but it is very strange looking (in following, lines were broken up):<br><br>ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ</div><div class="gmail_default" style="font-size:small">ZZZZZZZZZZZZZZZZZ]<br>)iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii</div><div class="gmail_default" style="font-size:small">iiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii</div><div class="gmail_default" style="font-size:small">iiiiiiiiiiiiiiiiiiiiiiiiiiiix!<br><br><b>Andrew </b>- I tried again to create the EDL undo crash and still could not, but I still have not booted the older distros and 32-bit to check them.  I hope to have time tomorrow to  do that and still test the netbsd patches from January 12 on those partitions.  Maybe there is a better solution to fix the EDL undo crash because the hope is to never crash.<br><br><b>BTW</b>: filename.opts is one feature of CinGG that is underutilized. But it is not that well explained in the manual.<br><a href="https://cinelerra-gg.org/download/CinelerraGG_Manual/Raw_Input_Opts_File_Video_A.html">https://cinelerra-gg.org/download/CinelerraGG_Manual/Raw_Input_Opts_File_Video_A.html</a><br><a href="https://cinelerra-gg.org/download/CinelerraGG_Manual/Speed_up_Ffmpeg_plugin_usag.html">https://cinelerra-gg.org/download/CinelerraGG_Manual/Speed_up_Ffmpeg_plugin_usag.html</a><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jan 22, 2023 at 7:54 AM Stefan de Konink via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
When editing with Cinelerra (current git) I experience frequently that my <br>
entire system hangs after scratching through either the timeline or the <br>
viewer. As experienced before I have noticed that Cinerella eats a lot of <br>
memory.<br>
<br>
The total amount of assets I have currently in my project is about 70GB, my <br>
system memory is 16GB, and yesterday I have added 8GB of swap (normally no <br>
swap).<br>
<br>
It seems that with every video that I preview my memory usage significantly <br>
increases, but is never released. I think we have discussed this behavior <br>
on the mailinglist before being that the indices never get released. But <br>
still the amount does not make sense to me. <br>
<br>
As user my expectation would be that when I would close the *viewer*, the <br>
memory would get released, especially when the content is not placed on the <br>
timeline.<br>
<br>
Are there any statistics available on the memory usage what goes where?<br>
<br>
Practical question: is it possible to have a different path for the <br>
emergency backups than /tmp?<br>
<br>
-- <br>
Stefan<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>