[solved] Publish from two hosts simultanously

Here’s a video showing the problem; https://www.youtube.com/watch?v=4lnqGKzzT2A&feature=youtu.be

This is all run from the desktop, so it can’t be anything to do with the network. Also here are the batch script I’m using in the video;

set PYTHONPATH=%PYTHONPATH%;%~dp0\pyblish-win\pythonpath;%~dp0\pyblish-win\lib\pyblish-x\integrations\maya
set PYBLISHPLUGINPATH=%~dp0\pyblish-bumpybox\pyblish_bumpybox\plugins;%~dp0\pyblish-bumpybox\pyblish_bumpybox\plugins\maya;%~dp0\pyblish-deadline\pyblish_deadline\plugins
start "Pyblish Development" "C:\Program Files\Autodesk\Maya2015\bin\maya.exe" %*
set NUKE_PATH=%~dp0\pyblish-win\lib\pyblish-x\integrations\nuke
set PYTHONPATH=%PYTHONPATH%;%~dp0\pyblish-win\pythonpath
set PYBLISHPLUGINPATH=%~dp0\pyblish-bumpybox\pyblish_bumpybox\plugins;%~dp0\pyblish-bumpybox\pyblish_bumpybox\plugins\nuke;%~dp0\pyblish-deadline\pyblish_deadline\plugins
start "Pyblish Development" "C:\Program Files\Nuke9.0v4\Nuke9.0" %*

Thanks @tokejepsen, that clarifies the problem. I’ll have a closer look at this.

I’ve devised a simple test, it would be great if you could test this out on a machine you experienced the problem on.

You will need…

…two terminals or Python interpreters, one per “host”. One will register a particular plug-in collecting a particular Instance, and the other will collect another. The test is to see what happens when Pyblish QML switches between the two contexts.

You will run…

…one at a time, from either a terminal or an IDE. The first one will launch QML, the second will refresh the previously launched QML. Just make sure you have pyblish_win/pythonpath on your PYTHONPATH, it will enable the appropriate Python interpreter for/and PyQt5.

snippetA.py

import pyblish.api
import pyblish_integration

class CollectAlpha(pyblish.api.Collector):
  def process(self, context):
    context.create_instance("Alpha Instance")

pyblish.api.register_plugin(CollectAlpha)

pyblish_integration.setup() # Might take a moment..
pyblish_integration.show() # Brings up Pyblish and the Alpha Instance

snippetB.py

import pyblish.api
import pyblish_integration

class CollectOmega(pyblish.api.Collector):
  def process(self, context):
    context.create_instance("Omega Instance")

pyblish.api.register_plugin(CollectOmega)

pyblish_integration.setup()
pyblish_integration.show() # Refreshes the running Pyblish with the Omega Instance

You should see…

…when running the first snippet, the Pyblish QML GUI and a single Instance - Alpha Instance. The second snippet should refresh the GUI, and instead display an Omega Instance.

Let me know how it turns out.

Got it running, and executing the two scripts from separate terminals works. It refreshes pyblish ui with the correct instance.

What is the next step of testing? Doing it in two nuke sessions?

What those snippets are doing is exactly what each host is doing, so it’s odd that it works here but not in hosts. But yes, try running Nuke similar to how you ran the snippets. Try running it from as a clean of an environment as you can, ideally identical to where you ran the snippets from.

The good news is it’s fixable on your end, and not a technical or hardware limitation of sorts.

The snippets work in two hosts as well. I investigated after this, and found that if I run pyblish_integration.setup() in the host that isn’t working (refreshing the pyblish ui), it works from then on.

Any idea why running pyblish_integration.setup() again would make it work?

Can you make sure the integration is being loaded correctly? That your NUKE_PATH is set correctly?

It sounds like it isn’t being run, but I’m surprised Pyblish QML shows up at all if that’s the case.

When you launch Nuke, you should be seeing a port here:

import pyblish_integration.lib
print pyblish_integration.lib.port

The next time you run setup(), the port should be different. But if there is a port there to begin with, you shouldn’t be having any trouble.

Hmm, I getting this error when launching the second Nuke session.

Looks like an issue with permissions.

I tried running on an admin user, from the desktop and still getting this error. Then it can’t be to do with permissions?

Can’t say for sure, it doesn’t sounds like it, no.

Does it happen every time? Can you try running it without any ftrack influence and see if it makes any difference?

Just to be clear, you mean you ran it “As an adminstrator”? E.g. by right-clicking. And not that you were logged in as an administrative user when running it?

Yeah, it happens everytime. Its outside of ftrack, as it just running those batch scripts as before.

Tried both. Logged in as admin, and right-clicking.

I’m referring to the last line in the screenshot, looks to be related to an ftrack connection somehow.

Otherwise, it’s hard to tell, without physically being there to inspect it.

1 Like

Hey @tokejepsen,

Seeing as this works well anywhere but on your machine, as far as I know, I’ve got an idea for how to get to the bottom of it.

The primary thing separating your machine from any other in any given circumstance boils down to environment variables. So what I’ll suggest is a “deep clean” of environment variables in an isolated terminal from which we run and iteratively re-add current variables as we go.

It should take less than 20 mins, and should clear out which of them is responsible.

1. Deep Clean

This will remove all environment variables, but only within the current terminal, so don’t worry about anything happening to your global environment. That’s protected via the fact that the terminal itself isn’t an admin process (don’t run it as an admin if you want to be sure).

clear_env.bat

@echo off
if exist ".\restore_env.bat" del ".\restore_env.bat"
for /f "tokens=1* delims==" %%a in ('set') do (
echo set %%a=%%b>> .\restore_env.bat
set %%a=
)

Once run, your environment will be empty, apart from read-only variables.

before

$ set
ALLUSERSPROFILE=C:\ProgramData
APPDATA=C:\Users\marcus\AppData\Roaming
asl.log=Destination=file
CLINK_DIR=C:\Program Files (x86)\clink\0.4.4
CommonProgramFiles=C:\Program Files\Common Files
CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files
...

After

$ clear_env
$ set
prompt=$p$g

It will create an additional file, restore_env.bat which you can run to restore the environment to what it was, and more importantly, to see and inspect what you have.

2. Run

From here, you could try and run a host, but you’ll find you can’t because there are certain system variables it expects to find.

From your restore_env.bat, cut out the lines with these variables in them and paste them into the terminal.

HOMEDRIVE
HOMEPATH
PATHEXT
PROCESSOR_ARCHITECTURE
PROCESSOR_IDENTIFIER
PROCESSOR_LEVEL
PROCESSOR_REVISION
ProgramData
ProgramFiles
ProgramFiles
ProgramW6432
SystemDrive
SystemRoot
TEMP
TMP
USERDOMAIN
USERDOMAIN_ROAMINGPROFILE
USERNAME
USERPROFILE

Next we’ll need Pyblish.

$ set PYTHONPATH=c:\pyblish_win\pythonpath
$ set PYTHONPATH=c:\pyblish_win\lib\pyblish-x\integrations\maya;%PYTHONPATH%

Now launch two hosts.

$ start "" "c:\Program Files\Autodesk\Maya2015\bin\maya.exe"
$ start "" "c:\Program Files\Autodesk\Maya2015\bin\maya.exe"

At this point, your computer and my computer should be roughly identical.

Try running Pyblish from both hosts.

3. Find the problem

If the above worked, then we’ve isolated the problem to one or more of the environment variables captured in restore_env.bat.

From here, keep cutting out variables and paste them into the same terminal as before, launch a host and test as you go. When you start experiencing the problem once more, you’ll know which variable caused it.

I’ll have a look at this, when I get time but its not just on my machine. This happens on all our machines.

It’s possible it is site-wide related. If we figure it out on one, we’ll likely find it for all.

To confirm, @mkolar where you also having this problem?

Not that we’ve noticed. I have people running houdini and nuke simultanously all the time and publishing seems to work fine. We’re not running any maya currently but will from next week. I can test the combination of the two then.

And two nuke sessions at the same time?

I followed the process, and I still have the problem. One thing I noticed was that I don’t have “USERDOMAIN_ROAMINGPROFILE” enviroment variable, but “USERDNSDOMAIN” instead.

Don’t know if that would be a problem?

Excellent. The missing environment variable might be because we’re running different OSs, I’m on Windows 8, you’re on 7?