Our studio is having issue with “broken pipe” issue, which we speculated the cause coming from tk-desktop v2.7.12, which is automatically generated in bundle_cache.
So far, we only bandaged it by constantly deleting “.shotgun” directory to clear out the cache, but same problem arises soon after as the desktop automatically downloads tk-desktop v2.7.12.
To bypass this,
We are trying to set tk-desktop version to 2.6.9 as that is our default in “engine_locations.yml”, which led to no success.
We also tried to set custom location for the tk-desktop by setting custom engine locations utilizing our own yml file and inserting lines in “engine_locations.yml”, which also didn’t work.
Help on how to set custom version for tk-desktop would be greatly appreciated.
Thank you!
You would need to override the site config with your own config so you can force the version of tk-desktop that loads when SG Desktop loads up.
Much appreciated!
Mind elaborating more on where the “site config” where it would be?
We are currently using rocky linux 8.8 in closed network environment.
A site config is a Pipeline Configuration which has no assigned Project.
When Sg Desktop and Sg Create start up it loads the site config first which will get you (in the case of Sg desktop) to the Projects Screen.
If you don’t have your own site config defined then Desktop will load the latest available config from ShotGrid (GitHub - shotgunsoftware/tk-config-basic: The configuration driving the Flow Production Tracking Integrations.).
This also defines which desktop engine version runs because it is started while the app loads.
Once you load into a Project config toolkit bootstraps a new python process into the chosen configuration specifically for that project (however the desktop server is not started again because only one instance of that should be running).
If you want to take over and define the behaviour of Sg Desktop startup and the specific versions of the engines and frameworks, then you can create a Pipeline Configuration, call it Primary and do not assign it a Project.
Then configure it how you do it usually, either by uploading or linking to a config on disk/uploaded zip file or by using the legacy centralized config setup paths.
Just to warn though, test this on a staging site or with user restrictions first because a site config affects, as the name suggests, the whole site and everyone using it.