So strangely this happened to us today on 2 computers. Seems to be difficult to reproduce though. I’ll try updating to newest version and go through steps in the thread to see if it helps
Yeah, try netstat -a -b | more and see if there are anything being used on 6001-6002
Soo look at these fellas. It just happend in houdini when nuke was opened. Tons of reports on the same port.
1 Like
That shouldn’t be a problem, they aren’t actually doing anything, but are awaiting clean-up by the OS. They will idle for a few minutes, possibly hours, and then go away.
It’s the LISTENING state you will want to look out for. There should only ever be a single LISTENING state on a given port.
Aha.
Well it seem like I have houdini and nuke listening on the same port here at the same time.
This can happen if you force-quit Pyblish QML while having hosts still running.
The problem is that the hosts still broadcast “heartbeats” to Pyblish QML at even intervals, and as soon as you quit it and start it again, it will record the port of the heartbeating client when it comes in. If then Nuke heartbeats before Houdini that one particular time, their port numbers will get mixed up.
Should resolve itself shutting down all hosts, and then opening them back up. Force quitting of Pyblish QML generally shouldn’t happen, but it can be supported, it just isn’t yet. Safest thing to do is the above.
You can tell which port a host is listening on like this.
import os
print os.environ["PYBLISH_CLIENT_PORT"]
# or
import pyblish_integration.lib
print pyblish_integration.lib.port
This same port number should then be reflected in the Terminal of Pyblish QML when running it from this host.