 |
The print statement was removed earlier. Will close in a day or 2. |
 |
Seems to work with tiff and exr :} There is some sort of debug print left, but it doesn't hurt much, may be leave it there until next release (I'll try to stress-test this feature more)? ---- BRender::set_video_map(5600, 2) BRender::set_video_map(5601, 2) BRender::set_video_map(5602, 2) ----- |
|
|
@Andrew-R A fix for reported problem has been checked into GIT. "move brender set_video_map update to write_frame_done" More later. |
|
|
patch (this one was already send some time ago to mail List, but just in case you missed it ..) If you apply patch and run Cin with background render set o OpenEXR - it surely will crash too on playback of region you already rendering slowly ... . But I tried with standard choices like tiff and png just to be sure about bug being confined to OpenEXR loading ..it and it turned to be generic? OpenEXR as brender is not very fast, but my point was to use 32 bit per channel floating point formats, so all those (possible) errors accumulating from float-> 8 bit int rgb conversion if you work in RGBA-float will not show up ....
FORMAT_brender_exr_added.diff (452 bytes) |
|
|
Also, while complete not based on this commit https://github.com/olive-editor/olive/commit/27effb9473e66d3d40866df740b148bcb6e02d4a " use OIIO DWAA for cache " I was also experimenting with 'EXR for background render' and this was exactly how I found this bug :} |
|
|
Also, I was looking in Olive (video editor using qt5) git, and found those two lines: https://github.com/olive-editor/olive/commits/master?after=e42ba3f9d4042eb062e0575ac3af8b187f1e064c+1189&branch=master "made auto-deleting cache on close an option" "added disk preferences pane and the ability to set the disk cache loc… " I think this functionality close to Cin's background render, so solution like 'remove brender files on close' actually might be working idea (but still, I'm not sure if such solution will work well in renderfarm setup, I only tried one instance of Cin running locally, while I think I saw few 'cin -b /tmp/long-string-of-letters-and-numbers' processes anyway) |
|
|
> Here is the problem with CinGG deleting them -- When do you do this? When you quit out? I think? Or what happen when I set background render to one type of files over same region, and then after it worked, decided to switch filetype? It will be confused, I think ... May be (yet another!) preference, like deleting background render files on quit/disable event ? Also, I use /dev/shm for speed (because my hdd where my real /tmp is resided is not speed daemon), and other users may want to put those files on fast NVME/ssd :} |
|
|
"Also, even if I un-toggle background rendering and red-brown bar disappear from timeline - files created during its run still around even after I quit CinGG ... Isn't this a bug, too?" Suggestion, which should be added to the manual, is to plan on putting the files in /tmp (like is the default) so that on most systems, when you reboot they will automatically be deleted. Here is the problem with CinGG deleting them -- When do you do this? When you quit out? So if you are being called to dinner and you want to hurry, then instead of quitting right away, Cinelerra is fooling around deleting these files and your food gets cold. Do you have a better suggestion? |
|
|
Also, even if I un-toggle background rendering and red-brown bar disappear from timeline - files created during its run still around even after I quit CinGG ... Isn't this a bug, too? (those files can be big, and will eat disk space ...for now I manually delete them after each test run) |
|
|
I watched directory where CinGG was creating brender files (pressing and holding ctrl-r in Midnight commander) - sometimes 0-sized files appeared there, and then after some time replaced by properly-sized files. may be check for this case (0-sized file) in readers? Ah, no, files not created in instant either (currently I recompile CinGG, so machine under load, and I can watch this process of file creation in slow motion). Another idea was to add .lock file in writers, remove it when file is surely written, and watch for this .lock file in readers .... |
|
|
Read the dump and GG was able to reproduce using Big Buck Bunny. He says "yes" that is a bug. He is looking at it now but do not know how long that will take. You analysis of "probably by reading not-yet written file?" sounds like a good possibility. |
|
|
cinelerra_8190.dmp (147,185 bytes) |
- Anonymous
