Shotgrid Sync Hierarchy error

Hi all, first post!

I’m doing a test run of Shotgrid sync, bringing a project in through the Synchronize Shotgrid → AYON button. The event spawns but errors out.
For background, ASH and the SG processor/transmitter are running, and Ayon adds a whole bunch of fields to the SG project, so the API key works.
The exact event error is “An error ocurred while processing the Event: ‘sg_episode’”, and I’ve attached a screenshot of the processor’s log. My guess is it’s building Ayon’s folder hierarchy at this point.

Log says “sg_episode” on SG is causing a freakout, however no such entity exists, the default Episode entity is simply “episode”. Could something be misconfigured in SG? The last DEBUG line shows that a key:value in navchains is set to ‘Sequence’: ‘Sequence.sg_episode’. This may be more of a generic SG question, but is this something that can be worked around? I’d be grateful for any pointers

Hi @reecemulley ;

thanks for takign the time to write here;

I’ve just released a new version 0.3.2 that fixes several bugfixes, so should be available via de bootstra/marketplace soon.

Regarding the error; looking at the tracking_settings (what the ayon-shotgrid uses to figure out the “project hierarchy” ) it says displays, for sequence: ..., "Sequence": "Sequence.sg_episode", ... and that is what it’s failing at finding, the Sequence should have a field that’s sg_episode acording to the tracking settings, do you mind sharing a screenshot of the tracking settings for your project (for each entity) or a simple description, as an example:

Project Hierarchy:
 * Episode (flat hierarchy) 
 * Sequence (Episode > Sequence)
 * Shot (Sequence > Shot)
 * Asset (flat hierarchy)

Cheers!

Hi @Minkiu , great to hear

Yep, bingo, it was fixed by changing the project hierarchy in the project’s Tracking Settings page. Sequence hierarchy was set to “Don’t show a navigation path for Sequences”. Changing it to “Episode > Sequence” fixed this error.


Is it recommended to keep Asset as a flat hierarchy? Traditionally we’ve used “Type > Asset”

1 Like

Nice!

Is it recommended to keep Asset as a flat hierarchy? Traditionally we’ve used “Type > Asset”

I’ve normally have it as Type > Asset in my instance, so you should be fine.

Let me know how it goes!