On Fri, Sep 1, 2023 at 1:59 AM Andrew Randrianasulu <[email protected]> wrote: > > > > пт, 1 сент. 2023 г., 01:27 Phyllis Smith <[email protected]>: >> >> Just FYI: >> My comprehension of this bug with Background Rendering change of file format >> is still missing mostly due to lack of time yesterday, but I will follow the >> discussion and try to understand it. Thank goodness Andrea was able to >> follow it and verify the error/fix. But I did fix my local copy of the >> Release Notes to correctly state: >>> >>> Reading error handling bug for background rendering in fileexr.C when do an >>> on-the-fly compressor >>> >>> switch has been fixed. >> >> Today, using the previous GIT, like Andrea, I have not gotten any crashes >> yet. >> >> However, it may be that changing this background rendering File Format >> requires the same type of restart of CinGG as when you change your >> Appearance of the Theme from Cakewalk to SUV or whatever. Maybe that would >> be preferable to "Try/Catch" in only fileexr.C?? > > > Well, it seems some deeper layer of rendering stack in cinelerra does not > check (if we change type of image file in bg render dialog without stopping > said bg render) type of file by signature and just feed incorrect file to all > native image read functions, not just openexr. > > So, I guess some "programmatically disable/enable bg render if preferences > for it change" might be good idea, along with user reporting (gui message) of > unwritable/nonexisting directory there and may be button to remove prev bg > render data like we can remove indexes manually. > > But this is bigger change, I yet to try to implement those ideas... > > I was worrying about openexr behavior too, esp if used with external library, > but this case seems to work fine, too .... at least on Slackware 15.0 i586. > > I do not think we should worry about this mechanism too much - it was around > since long time, and in this case library itself throwning exception, so I > guess we supposed to catch it in our code!
Also, I tried 64-bit Rosa 2016 (gcc 5.5.0, glibc 2.24) build and it works ... Thing is, my initial testing was with brender files on tmpfs (/dev/shm), so may be try to put brender files there and see how it goes? (yes, /tmp in modern distros often mounted to /dev/shm anyway, but in my case it is not and I prefer to keep it this way. > >> >> On Thu, Aug 31, 2023 at 1:31 AM Andrea paz <[email protected]> >> wrote: >>> >>> > Thanks! Did you try yesterday's scenario with bg render set to jpeg, >>> > enabled, then set to any other compression / filetype, and re-enabled via >>> > menu so you have red bar at top of topmost video track but at this point >>> > it made from wrong image type so prev. version of file reading routines >>> > were crashing? if you position playhead there? >>> >>> I don't quite understand the problem. >>> 1- No crash, but I don't know if I've done the steps you described >>> correctly. >>> 2- Creating a BRender in jpg, then disabling the BG. Going into >>> Preference and changing the BR from jpg sequence to EXR (and PNG) >>> sequence, creating a new BRender, I still have the jpeg sequence >>> active and no sequences were created with the other formats. >>> 3- Closed and restarted CinGG; created new BRender in tga: all OK. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
