<div dir="ltr"><div class="gmail_quote"><div><span class="gmail_default" style="font-size:small">Mark,</span></div><div><span class="gmail_default" style="font-size:small">Now that you have found a workaround, I do not know if you want to continue to work on resolving this.  If so, don't bother reading the rest of this.  Or how much more time to test you want to do.  Depending on your goal:<br></span></div><div><span class="gmail_default" style="font-size:small"><br></span></div><div><span class="gmail_default" style="font-size:small">?? do you want to build yourself (if so, I have Fedora 29 on a partition and am compiling my latest CinGG tar there right now to see if I can reproduce the error you are getting.  It has the same kernel of 4.18 as RHEL8 and glibc of 2.28 as you mentioned - Fedora 28 is earlier than that).  I could also try to download RHEL8 as a developer for free but I don't know how far I would get with that and reproducing the error.<br>?? OR would you prefer to just use AppImage if vdpau worked? (if so, I can work on trying to figure out a solution because others have the same issue).<br><br>?? have you tried this easy test of using the default configuration file to make sure indexes are rebuilt and there is nothing strange in your cinelerra_rc file?  ,.e.    CIN_CONFIG-/tmp/bcast1 ./bin/cin<br><br>About:<br></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail_default" style="font-size:small"> compiled it. It worked for a while but now it crashes with the following when I hit the play button. There were some system updates installed in the interim.</span><br><span class="gmail_default" style="font-size:small"></span></blockquote></div><div><span class="gmail_default" style="font-size:small">?? is it possible that the system updates included a technology called pre-linking, which supposedly "speed up a start of a binary which uses dynamically loaded libraries by linking these libraries in advance ("prelinking" the executable file) using the 'relocating' technique. This basically means that each time the binary is run, the shared libraries are loaded to a randomly chosen memory addresses, which may sometimes interfere with the addresses at which the program shared memory segments are to be attached." The reason I ask is because when I look up the error message you first reported of "could not attach shared memory" it talks about this error and a solution as follows:<br><br>Per the internet, you can disable prelink by editing /etc/sysconfig/prelink (set PRELINKING=no), then run /etc/cron.daily/prelink so the prelinking of the libraries in the system will be disabled. Fedora and Red Hat Enterprise Linux (RHEL) supposedly enable pre-linking by default which means I have been using it that way for years without a known problem. But I do not see a file called /etc/sysconfig/prelink on my Fedora 32.<br><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div>RHEL8 uses glibc 2.28, kind of annoying they stayed there as many newer things want a later version. They have a habit of backporting things though, including kernel changes, such that the conditional compile based on versions sometimes fails and a special case for a Redhat kernel needs to be added. Who knows if they backported something in glibc?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><span class="gmail_default" style="font-size:small"></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div> If I set the compiled version to not use any hardware accel, it still crashes. I don't think the vdpau issue and the crash are related. The crash is my big concern obviously, as any work not saved is lost. <span class="gmail_default" style="font-size:small"></span> </div></div></blockquote></div></div></blockquote></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_quote"><div></div></div></blockquote></div></div></blockquote><div><br></div><div>Why would it not crash if there is another video on the timeline below what I am playing? At least that is a workaround. It can be another copy of the same track.</div></div></div></blockquote><div><span class="gmail_default" style="font-size:small">Good question!</span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div><br></div><div>Thanks for taking up the mantle of the open source Cinelerra gg. I was very peripherally involved with Cinelerra CV in 2011. I provided a patch for SOWT audio and communicated with Einar at that time. I see that is now handled by ffmpeg. <br></div></div></div></blockquote><div><span class="gmail_default" style="font-size:small">We just want to make sure Cinelerra lives on and stays relevant after all of the hard work you and</span> <span class="gmail_default" style="font-size:small">many, many others have done !</span></div></div></div>