Multitrack publish - issue on linux/remote box

Flame Flame Questions
1

I had this on 2 occasions now , but didnt yet have the time to reproduce it.

  1. publish 3 plates from 3 tracks wih batch groups from a mac.

  2. Open batch group on a local (as “in the network” mac - all is “good” all 3 plates show up in batch. (plate02 and 03 never have their segment openclips linked but thats a known issue)

  3. someone on a remote / linux system (only had this on remote linux and we dont have local linux) opens the batch group, now plate03 just shows up as “clip missing” (red text) for the user with no path when alt+ clicking it - and plate02 is suddenly the same as plate01?

what is going on here, thats super odd behaviour, ill trt to find the time to see if its juat a remote vs local problem (maybe the oublished batch somehow connects back to some framestore for whatever reason? or idk.. its weird)

1 Like
2

mount points?

3

there is likely some errors being put into the shell that will tell you exactly what is going on with the pathing.

1 Like
4

well plate01 shows up fine and the data is all there, same mount points (via lucidlink)

5

Busch Beer GIF by Busch

1 Like
6

if I open the file on lucid on my macbook remotely its fine tho.. odd.

How would lucid interfere with what batch is loading?

7

mount points?
permissions?

8

image
image1920×428 103 KB

Looks like its trying to connect to the original flame it was published from?

9

first thing I found, published batch has references to the Gateway server even though there is no point, however plate03 clip node (the one that turns red) does not have a gateway hostname just a storageID (whatever that is)
the paths in there are all correct but there must be something super weird.

ChatGPT analysis of the unreadable batch files::

image
image830×1369 94.4 KB

10

If this is pre-2026, there is still the concept of a Wiretap Gateway (which was always a terrible thing to begin with). The person imported that clip thru that instead of the “raw” filesystem path. You need to re-import that clip then it will work.

There is a special environment variable that ADSK guys made for us to hide all WTG in the Media Panel to avoid this situation from ever being possible. If you want it I can look it up and send.

In 2026 they remove this whole horrible concept.

11

yea this is 2025.2.3 ,

So this is intended behaviour? oO i am publishing the clips to disk and the created batch file is referencing stuff THROUGH wiretab gateway.

man that sounds horrible, so everytime I even open this locally it still goes through the other flame?

12

Seems to me that is what is happening. You must make sure to import everything thru the raw filesystem and not thru a Gateway.

Add this to your environment variables:

setenv DL_REMOTE_GATEWAY 0   #Hide MediaGateways.  Show local devices only.
1 Like
13

thanks ill give it a go!

14

sadly that env variable did not fix it for me.

I submitted a video and files to adsk and they replicated the behaviour.

and here are the files, if anyone feels like following along for the riiide:

15

It won’t work retroactively. All it does is hide the media gateways so people won’t choose them in the future. If you already imported media via a Gateway, that is locked in.

16

Well thats the thing, I did not import anything, the batch group gets created by flame during publish,

flame writes out media and then the clip nodes in the flame-created-batch link to that media.

So nothing was ever imported by any gateway or anything.

17

Thanks for reporting the issue to the Support team. We will have a look at this when time permits and will get back to you.

2 Likes
18

of course.

This also sort of includes the known issue with multitrack published batches not linked to the segment openclips by @Jeff

hope you can find something, maybe also this isnt a issue on 2026? wouldnt know , still cant upgrade will wait a few more versions i guess :confused:

2 Likes
19

I joked on the beta forum awhile ago, that “I’ll pick back up in 2027”. Not a joke anymore. Still 3 major versions back for reasons out of our control.

20

The issue you have seen (Publishing multi-track shot does not reference Open Clip from content not connected to the back clip) is the same issue reported by @Jeff some month ago. This is not new and dates from the original Shot Publish feature back in 2015. The workaround is to manually replace the clips to the Open Clips and save the setup (you could also probably do this using Python to remove manual edits of the setups).

We will have a look and will let you know when a solution is available.

1 Like