[Cin] fileexr reading error handling

Andrew Randrianasulu randrianasulu at gmail.com
Fri Sep 1 01:26:34 CEST 2023


On Fri, Sep 1, 2023 at 1:59 AM Andrew Randrianasulu
<randrianasulu at gmail.com> wrote:
>
>
>
> пт, 1 сент. 2023 г., 01:27 Phyllis Smith <phylsmith2017 at gmail.com>:
>>
>> 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 <gamberucci.andrea at gmail.com> 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.


More information about the Cin mailing list