Mocha OFX Plugin Nuke Render farm issues

Hello everyone!

We currently experiencing issues rendering with the Mocha Pro 2020.5 (v7.5.1) OFX plug-in in Nuke 11.3v2. We are using CentOs 7. If we have a Mocha Pro node in the scene and send it to the render farm we are running into this error:

QSocketNotifier: Can only be used with threads started with QThread
qt.qpa.xcb: could not connect to display 
qt.qpa.plugin: Could not load the Qt platform plugin "xcb" in "" even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
Available platform plugins are: minimal, offscreen, xcb.

The node just needs to be in the scene, the error will occur even when the node is not part of the current node tree. Rendering locally works with no issues. We suspect that it might be related to the fact that our render blades do not posses any graphic cards.

Does anybody has more information on this?


I will tag @martinb to flag this.

Hey @fabian.geisler how are you running the Nuke app on the headless systems?

This may be related to a limitation with mocha on a headless Linux server. Our plug-in is trying to connect to an X server at render time and not correctly handling the case where none is present.

On Centos 7 you may be able to use a virtual frame buffer on the render farm by running the Nuke app via:

xvfb-run /path/to/the/nuke/app

The default arguments for sleep and server are 3 and 99 respectively, which should help stop the problem from occurring.

If you run xvfb-run --help you can see these options.

Let me know if running via xvfb alleviates the problem.

Hi @martinb! Hi @maryp!

Thanks for getting back to me on this. Unfortunately your suggested workaround is does not work for us. Installing X server on our blades is too much for us atm. We will try to fool the blades to think they have a screen. There are some dummy plugs for HDMI and VGA. Will let you know how this goes.
Obviously it would be great, if you could alleviate this issue on your side or write a clear warning somewhere noticeable.
Thanks again!


Hey @martinb

According to the release notes in 2021 this is still an issue.

Do you know if this is going to be fixed?
We cannot use the workaround either and have resorted to telling artists to not use Mocha on the render farm.


Hi Alex thanks for letting us know this is still a problem. I’ll confer with the dev team and see if there are any updated solutions.

Awesome thanks!

Hi @martinb!

Just wanted to let you know that the issue actually has gotten worse for us:
On some machines it is enough to have the Mocha Plugin in the OFX_PLUGIN_PATH to run into the error. We can also verify that the error is also occurring on Nuke 12.1v4 and Nuke 12.2v3.

Hope you will have a fix for this soon.


Thank you, Fabian, I will tag @martinb and @jps and let them know.

Just an update on this:
We should have a potential workaround incoming with the v8.0.2 update. I can’t give you a date yet as we’re still in the mix with a few other fixes.

Thanks for the update @martinb!
Looking forward to it.

I’m still experiencing this issue with v8.0.3. Is there anything I need to change on my end?

Using Nuke-11.3v3

Which Centos version @andreas1 ?

Are you getting the exact same error? I ask because this was definitely fixed, so you may be encountering a different error.

Please give us full details of the problem and the specific errors.

Hello There! We’re experiencing a similar issue with the Mocha OFX Plugin for Nuke on our Deadline render farm.

Whenever we submit a nuke file that contains a MochaPro node inside it, the job will fail with this error:

Error: FailRenderException : Dialog popup detected: Title “Error”, Message “LoadLibrary failed with error 87: The parameter is incorrect.”

We’ve tried just disabling the MochaPro nodes in the comp, but that is not enough. We have to completely delete the MochaPro nodes then it will render just fine.

Any help would be much appreciated!

Software Details:

  • Nuke 11.3v1, 64bit, built Dec 12 2018
  • Mocha Pro Plugin 2022.5, Version 9.5.2 build 9.g13b278477fd3, Build Date May 26 2022
  • Windows 10 Pro

Render Node Details:

  • Windows 10 Pro
  • 24GB Ram
  • Intel i7 980
  • no integrated graphics or graphics card
  • it’s just a really old render node, but’s all we’ve got to work with for now

Hmm, that’s a new one. This error appears to be related to graphics drivers.
Since you only have an Intel chip in there it’s possible you need to configure the mocha render node to turn off GPU processing, as Mocha may be attempting to utilize the OpenCL properties of the onboard CPU.
If you post your mocha.log from the render node, it might show us some more details. You can find the log on Windows here:


Here is the log file you requested, there’s not much in there though…
mocha.log.txt (30.4 KB)

I’m attempting to turn off the GPU processing setting now, will report back with the results after some testing.

I’ve tried turning off the GPU settings in my desktop preferences, and that setting seems to stick on my desktop and work just fine. Unfortuately the job still fails on the farm with the same error:

Error: FailRenderException : Dialog popup detected: Title “Error”, Message “LoadLibrary failed with error 87: The parameter is incorrect.”

I have no clue how to disable the “Use GPU Processing” setting on the render farm machines… is there a preferences file or something somewhere that I can edit? (windows 10 pro render node, and the OFX Mocha Pro Plugin 2022.5 for Nuke)

Note: I would happy if we could just leave a disabled MochaPro node in the nuke comp and use that on the farm without it crashing. That way we can just pre-render it on a desktop and still have it disabled in the comp file in case we need to make changes later.

With the help of our I.T. guys, I was able to use regedit to disable the various ‘Use GPU’ settings on the farm:

HKEY_CURRENT_USER\Software\BorisFX\Mocha Pro Plugin 2022.5

  1. EnableCLIImageProc = false
  2. EnableCLRemover = false
  3. EnableCLTracker = false

Unfortunately that did NOT solve our issue.
Any further help/suggestions to try would be much appreciated.

From what I can see from the log, the initialization is failing quite early in the loading of the plugin as it’s not even getting to the hardware check phase.
I’ll need to confirm with the dev team what the next approach would be.

Is the windows machine headless?

Yes it is.