Maya 2018 QT binding issue with sbsbaker

[NevTD]

I have a GUI that launches sbsbaker, sbscook and sbsrender processes from Maya.
It works fine as long as the GUI is a child of Maya.

However, if I attempt to detach the GUI from Maya (either subprocess or QProcess), so that the subprocesses run in the background without blocking Maya, I end up with the following error, only for the sbsbaker tasks:

Code: [Select]

(None, 'This application failed to start because it could not find or load the Qt platform plugin "xcb"\nin "".\n\nAvailable platform plugins are: console, linuxfb, minimal, offscreen, xcb.\n\nReinstalling the application may fix this problem.\n'
Any idea what might be causing this?

Using:
CentOS Linux release 7.3.1611
Maya 2018.2
Qtpy for bindings
SAT 2017.2.2-50

[DavidAllegorithmic]

Hi,

I might need some more information in order to help out here.
My speculation is that somehow sbsbaker is being run from a directory or environment that has a bunch of qt dynamic libraries in path that are not compatible with the binary rather than the ones in the batch tools causing issues. Exactly why that would happen when running it detached from maya I'm not sure.

Some follow up questions:
What do you mean with detatching the gui from Maya? Do you mean running it from a python script not run through the maya interpreter with your own pyside2 installation or something else?
When running sbsbaker it will always be run through a subprocess call and if you use subprocess to run an external python script invoking batchtools.sbsbaker you are essentially just getting two levels of subprocesses for no reasons. batchtools.sbsbaker returns the process object from a subprocess call. If you start it from a separate thread or manage its running in a different way than just calling wait you should be able to have it run asynchornously in Maya without jumping through any hoops.

[NevTD]

Hey David,

So to clarify; I'm creating subprocesses for the command line sbsbaker/sbscook/sbsrender processes and pooling them as threads into a single "task" for each UDIM. The task is then run as a subprocess, which will bake all the maps concurrently, followed by cooking the sbsars and then rendering. The idea behind this is to run multiple UDIM tasks concurrently and this part is working fine on its own.

Also, I'm not currently using batchtools to do this, although I may in the future.
___
As for the issue itself:
The GUI is supposed to work inside and outside of a DCC (all necessary data is queried from the asset's USD files); in order to do so, we are using the QtPy bindings created to deal with PySide2/PySide/Qt5/Qt4. https://github.com/mottosso/Qt.py

If the GUI is launched from with the DCC, using the DCC's window as a parent, it will block the DCC from responding until all UDIM tasks are completed.
This isn't ideal for artists, so in order to keep Maya (or other DCC's) responsive, I detached the GUI from Maya so that the GUI window would have a new QApp, rather than Maya's window as an instance. I have tried detaching using both QProcess and launching the GUI as a subprocess, both work to create a stand-alone GUI; however, sbsbaker now produces the error below.
___
We are using REZ to manage our environments, so Maya is running in its own environment, with its own dependencies.
The GUI is also being launched from the same environment so it inherits all the dependencies of Maya's environment.
The only difference between running with Maya as a parent and on it's own, is that any libraries being loaded by Maya itself(pyside2 for instance) are not loaded in the detached GUI.

Now if I run the GUI in its own environment using QtPy, I have the exact same issue. But if I create the tasks without invoking the GUI, they run without any errors.
I have a hunch that switching from importing QtPy to Qt4 for the GUI, might resolve the issue; although it's not ideal. I'll need to test it out.

Hopefully that gives you enough info.