Bug 498160

Created attachment 177045 [details]
terminal output

I was able to use yabridge's blacklist feature to blacklist any VSTs that would crash kdenlive when scanned. The offending VST plugins all seem to have the same thing in common: they can't be used outside of Mixcraft. So, blacklisting these plugins won't keep me from using anything I wouldn't have been able to use anyway.

After clearing out the problem VSTs, I ran into another problem. After a while of scanning my VST collection, Kdenlive now crashes for a different reason: Too many open files.

Here is the terminal output of the error:
========================================================
terminate called after throwing an instance of 'std::system_error'
  what():  eventfd_select_interrupter: Too many open files
Failed to open metadata file: Too many open files
KCrash: Application 'kdenlive' crashing... crashRecursionCounter = 2
Aborted (core dumped)
========================================================

So it would appear that having a large number of VST plugins installed on my system is also a problem for Kdenlive.

After working through a number of issues trying to get Kdenlive to start, here is a summary of the issues that I'm seeing with the startup VST plugin scan:

1. The VST scan is fragile. If an element of the plugin scan crashes, it brings down Kdenlive as well.
2. On systems with many VST plugins, the plugin scan may exceed the system's limit for open files (1024), leading to a crash. Raising the system limit is necessary to work around this issue.
3. On systems with many VST plugins, the plugin scan may exceed the system's limit for open X clients (256), causing Kdenlive to hang. Raising the system limit is necessary to work around this issue.
4. If any VST opens a GUI element when scanned, that GUI element may remain stuck on the screen until Kdenlive is closed (e.g., Acoustica Pianissimo's sample loading indicator).
5. Kdenlive doesn't seem to remember what it has already scanned, so each time I start kdenlive, it has to scan all of the plugins all over again. This leads to Kdenlive taking several minutes to start, and system file and X client limits must be raised permanently, not temporarily.

This is a huge problem for me, as is makes the conditions to use Kdenlive quite adversarial. Furthermore, I have to blacklist plugins that are otherwise useful to me in other applications so that Kdenlive can start at all. (My previous statement that the crashing plugins were all restricted to a specific DAW turns out to be incorrect.)

It would seem to me that something like the following might need to be done to avoid app-breaking issues for people with a music studio's worth of VST plugins:

1. Plugins that fail to scan should be placed on a blacklist. Plugins that succeed scan should be placed on a whitelist. The startup scan should look for the existence of VST plugins. If the plugin is on the blacklist, it is ignored. If the plugin is on the whitelist, it is checked to see whether it has been updated or deleted. If updated, re-scan the plugin. This is generally how DAWs behave, and avoids long application start times caused by re-scanning already known plugins.
2. If possible, avoid a plugin scan failure crashing Kdenlive. Otherwise, when scanning a new or updated plugin, place it initially on the blacklist, and then if the scan completes successfully, move it to the whitelist. This way, if a plugin scan crashes Kdenlive, it won't crash on the same plugin every subsequent launch.
3. Make it possible to disable VST plugin support. Perhaps make the VST support opt-in in the settings if it continues to be problematic.

If there is some secret way to disable the VST scan, I would love to know as I have videos I need to edit.

Peace. 🕊️

Thank you for reporting and the attached debugger report.

It seems to be a MLT issue with "mltconnection.cpp" as reported here as well: https://forum.endeavouros.com/t/kdenlive-crash-on-startup-in-24-08-1/60286

I'm not sure if you can switch off the VST link in the settings.

Thanks for your report. First, regarding VST plugins crashing MLT/Kdenlive, there is a rather hiden way to fix this by creating a file called blacklist.txt in /usr/share/MLT-7/jackrack/

Then, in this blacklist file, you can put the names of the plugins to avoid, one on each line. For example:
ambix_binaural.so

So in your case it would probably be:
VBE-1 Vacuum Tube Bass Enhancer.dll

or maybe you need to blacklist the entire yabridge with this:
libyabridge-vst2.so

If you are aware of crashing plugins, it would be appreciated if you give us the their names so that we could include them in MLT's default blacklist.

Please test and let me know if this blacklist solution works as a first step.

🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!

Thanks for the info! I had switched to the Flatpak version of Kdenlive as a workaround, but I will install the KDE neon version instead and let you know how the blacklist works.

Well, the KDE neon packaged version of Kdenlive appears to no longer cause a VST scan on startup, so I'm not sure how to test the workaround anymore. I guess I'll have to mark this as "WORKSFORME".