Flame does not load OpenFX General plugin

[glevnerMYU4S]

We are working on an OpenFX plugin for Flame 2023.2. Until now, the plugin has loaded fine in Flame. After moving to a different machine running Rocky Linux, however, the plugin fails to load. More precisely, the plugin's Describe action is called, but its Describe In Context action is not, and the plugin does not appear in the Flame UI.

Details which may or may not be of any help:

• I have tried compiling with gcc 9.2.1 and gcc 8.5.0 with the same result.
• The Describe action tells the host that the plugin supports the General context, and half and float pixel depths.
• I have set the OFX_DEBUG_ALL environment variable. Resulting messages confirm the properties set by the Describe action, but give no indication of anything being amiss.
• The previous machine, where the plugin worked, was running CentOS 7.6. The new machine is running Rocky Linux 8.5.

Help?

Update. Only the Filter context works. This is unfortunate, because our plugin is not a filter node. But if the Describe action says the Filter context is supported, the UI allows you to create an instance of the plugin.

@Philippe_Jean 

[glevnerMYU4S]

I found a solution, albeit not a very satisfactory one. After installing some other OpenFX plugins (Neat Video, Sapphire), our plugin also loads correctly, with no changes.

[Philippe_Jean]

If the plugin started working after installing other plugins, I would suspect two possible reasons.  Either some library used by the plugin was missing and got installed by the third party plugin.  Or Flame ofx cache was not detecting an update in the plugin.

In the first case doing "ldd  plugin.ofx" (prior to installed the thirdparty plugins)  in the shell on the shared object located in the plugin.ofx.bundle/Contents/Linux-x86-64 directory should show the missing shared object(s).

In the case of a cache bug, you can remove the ofxPluginCache.xml file from the /opt/Autodesk/flameVersionNumber/status directory to force Flame to rescan the plugins from scratch.

[glevnerMYU4S]

Thank you for that. But given that it was only the General context that wasn’t working, neither of those explanations seems plausible. The same DSO is used for both the General and Filter contexts. 

[glevnerMYU4S]

No, this seems to be a Flame bug. If the user creates an OpenFX node in Batch, and the directory /usr/OFX/Plugins does not exist, Flame does not create the Load Plugin menu. It seems to conclude that there are no OpenFX plugins, even though there may be others (e.g. ours) in an OFX_PLUGIN_PATH directory. When there are plugins in /usr/OFX/Plugins, Flame creates the Load Plugin menu, and plugins found on OFX_PLUGIN_PATH are also handled properly.

[Philippe_Jean]

Flame does not create the Load Plugin menu if only 1 plugin was found during the scan.  Adding the open fx node auto load the only plugin found in that case.  There is indeed a bug in this case, it auto-use the Filter context.

[Philippe_Jean · Accepted solution]

The bug has been logged as "FLME-64808 Filter context is always used in Batch OpenFX when only 1 plugin exist"

[Philippe_Jean]

 "FLME-64808 Filter context is always used in Batch OpenFX when only 1 plugin exist" has been fixed in Flame 2025.