I really have no idea about why the "1 versus 0" makes a difference

Unfortunatly I don't know either. Maybe Andrew-R know?

just to clarify that NOW with the change in, your original Resize problem is working correctly also?

Yes. It works correctly. You are Great! Thank you!

PS_OffTopic: @cinadmin - I saw phylsmith2004 post thanks at the notification (because Phyllis wrote my nickname in the post) but I can only see that post after login. As guest user I can not see it. But, now, Forum seems to work better. Thanks!

So glad you verified this is working correctly.  I really have no idea about why the "1 versus 0" makes a difference but just to clarify that NOW with the change in, your original Resize problem is working correctly also?

It works very good. I think that, how you are written in MantisBT#547 (Phyllis quote: BUT I do not know for sure if that will undo the "Resize bug for Filelist type assets, such as png, has been fixed), the two issues below are connected

MantisBT 0000547, https://cinelerra-gg.org/bugtracker/view.php?id=547

MantisBT 0000530, https://cinelerra-gg.org/bugtracker/view.php?id=530

I tested the issues #547 and #530 with "CinGG-20210331-x86_64-older_distros.AppImage" release AND adding only your mod (to filelist.h) at "cinelerra-5.1-ub20.04-20201031.x86_64-static.txz" release.

The line in filelist.h:

int can_scale_input() { return 0; }

instead of

int can_scale_input() { return 1; }

So, I am here only to say,... Thank you so much!

PS: Sorry, I have a few of problems with Forum

Thank you very much for your efforts.

I'll test it soon.

OK, it is now fixed as far as I can tell and checked into GIT.

There is now a new AppImage for anyone who wants the fix instead of using the workaround.  It also contains the Autosave backup feature that can be enabled.

    https://cinelerra-gg.org/download/images/cin_for_newer_distros.AppImage

Thanks for your persistence. Thanks for your patience. And thanks for your example xml file -- I probably would never have been able to create the crash without that because I would not have known to set Playback to X11.  Also, if the box on the right side of X11 was unchecked, it would have been another workaround but who would even think to do that.

This was a 1 character change!! a 1 was changed to 0.  More details about the fix are in the Bug Tracker #547.

I know you have a workaround but having CinelerraGG crash is not acceptable to me.  The problem is that neither Andrea or I can reproduce the crash (Arch and Fedora O/S).  Andrew-R has a patch workaround also, but without being able to get a crash, it is impossible to know if it fixes the problem for everyone.

No further response is necessary as you have work to do.  Thanks for your persistence and I will at least keep trying to get it to crash here.  And perhaps temporarily add the workarounds you have developed to the manual for others to avoid loss of time/work.

Playback A X11 has to be changed to X11-OpenGL

Although I use Nouveau - which is not really 3D accelerated - and X11 should be the safest fallback mode.

It was just a stupid trial&error out of frustration. This shouldn't be the solution.

Nevertheless, JPEG background rendering works now with this setting

Still can't believe that ...

It is important to me for the next project.

Meanwhile I will work with PNG background rendering.

I will look at the information and files you provided and have asked Andrew-R to see if the additional information can help in regards to BT #547.  Since we recently lost our #1 guru, it may be difficult to figure this out -- just saying.

I keep that in mind with the files in /tmp

What works

Starting CIN_CONFIG=/tmp/bcast1 {directory where cinelerra is}/bin/cin and importing of one the clips

That works!

What doesn't work

Starting CIN_CONFIG=/tmp/bcast1 {directory where cinelerra is}/bin/cin and loading the original .xml file

What also doesn't work

Starting cin regularly and importing one of the clips into a plain project does not work.

Logfile

See attached the renamed dmp logfile.

Terminal output (render into JPEG):

RenderFarmClient::main_loop: client started
RenderFarmWatchdog::run 1 killing client pid 31248
BRenderThread::start 1 map=0 equivalent=0 brender_start=129 result=129 end=455
RenderFarmClient::main_loop: Session started from /tmp/cinelerra.1fab46b2-d130-4e0b-8b63-82b9c0a357d7
** segv at 0x561780b24fba in pid 31332, tid 31542
writing debug data to /tmp/cinelerra_31332.dmp
lock_items: 22
lock_frees: 20
signal_entry_recoverable: got SIGPIPE my pid=31493
signal_entry_recoverable: got SIGPIPE my pid=31493
signal_entry_recoverable: got SIGPIPE my pid=31493
signal_entry_recoverable: got SIGPIPE my pid=31493
Speicherzugriffsfehler

I read this and just give a try to set the output file format for background render from JPEG to TIFF at properties->performance

https://cinelerra-gg.org/bugtracker/view.php?id=547

While JPEG never works, TIFF and PNG always do. But the data written is dramatically high for a non exclusive SSD Cache Storage.

Meanwhile I use PNG compression (with compression ratio=1) and render the files into a 3 GB RAM drive.

Benchmark

I ran some tests to see whether PNG or TIFF could be an option.

A clip of 13s content length (additional 3s black at start and ending):

PNG ratio=6 -> 740 MB (only 2 threads utilized most of the time); 67s render time

PNG ratio=3 -> 802 MB

PNG ratio=2 -> 856 MB

PNG ratio=1 -> 872 MB; 56s render time

PNG ratio=0 -> 2700 MB

TIFF LZW -> 1600 MB; 32s

TIFF LZMA -> DNF, render too slow

JPG -> 60 MB, 26s; Crash at playback

Using high compression of 5 (or higher) results in really low rendering times because the rendering of the effects waits for the PNG only dual threaded compression task to  be finished. The size benefit is neglectable with compression ratio 2 and above.