My god. I’ll have to get on them then. Do you have a ticket #?
We tested this morning on the latest version of Flame and it’s still there. Zero Dropbox involved.
1 Like
Case #21947654
1 Like
Funnily enough I ran into this exact problem the other day. On site with a client, loading batches to a Mac-based Flame. Horrible load times… in the several minute range. Switched over to a Linux box over Teradici instead and everything loaded instantly. All the sources were on Lucid. Other remote artists also using Lucid did not have the issue.
Got home, same machine back on the original subnet loads the same batches in a second or two. This is new.
Same issue with gateway timeouts. Feels like someone moved a decimal place somewhere on the wait time because it wasn’t like this before.
I have the same issues with some random clip with version 2024.2.1. The clips are jamming the machine when I try to access them. They come from an archive of an other Mac .
I’ve seen it as well recently when I had to load an old setup that was saved to server to check something. Gateway error. Just sits there for ages. Feels like @cnoellert is right with a change in the timeout.
Hello. Does anyone know if this terrible bug has been fixed in 2025? It is nearly a showstopper for projects where we share ASCII batches.
Haven’t upgraded yet. As soon as I do I’ll definitely chime in…
we have only observed the issue with missing media , if stuff was rendered using rendernodes and the like it took forever to load and then at some point we got an error saying the media couldnt be found.
is that the same issue here? this was ona remote box using linux by @Sinan .
On another job in 2024 this was all fine even with remotes, same thing all the stuff on lucid
My issues were with read and import nodes referencing source material published out on the filespace.
That’s interesting. Some of the setups do have pre-rendered clips in them, like Neat passes. Maybe we should try exporting those passes out and reimporting them as new media, before sending the ASCII batch.
i havent observed that behaviour for us as long as we dont have any flame-generated media in a batch it loaded fast. 
Yep. That’s why it was so odd.
1 Like
yea make sure its all write file nodes that way it works, ifk about cached media…
are you using publish workflow to export these ascii batches? thats what we do
Can’t say I’ve encountered this issue.
I occasionally load a setup with missing media, but it loads pretty quickly.
Just to be clear, this is loading a batch setup, not timeline.
In my corner of the flame 2025 universe, the only observable/repeatable load delay concerns loading color management nodes that contain combinations of Sony Venice 2 Cine 709 information.
Inexplicably I see this in the shell: ‘Error while loading ColorTransformBuilder settings’ but the nodes eventually load.
1 Like
Have you made a request for read nodes like in nuke?
I remember batches getting horribly bloated and non functioning when batches were being shared for amends after the main job finished: the batch setups were still trying to look at the gateway through the original flame’s import address ie media was being imported through flame 1s wiretap into flame 2 to be worked on. And when flame 1 deleted the project, flame / had a hissy fit.
Not saying this is where we are at but my belief is that flame is perhaps not dealing with the way we are working in a transparent manner unlike other apps that don’t cache to a frame store.
remedy: openclip workflow, metadata archives, convert to local, etc.
This is with openclips though and all pathing was the same…
That’s why it was all so odd. I was on-site at a client, and I’m sure it was gateway/ip related.
1 Like
I just had this issue with 2024.2.1, and the only way around fit was to copy the media to a local volume on my Linux machine, disable networking, load the batch (it loaded instantly) and then replace all the media. I’m suspecting that that was something in the ASCII setup that was still referencing a network location that could not be found.
4 Likes