Timeline renders not beign invalidated on replace below

Wondering who else has this problem and if anyone has logged it allready as a defect as its very annoying:

  1. i have a timeline with 2 layers, openclip on V1 and a logo on V2 , both are connected to other segements in different sequences, both segements are rendered

  2. I update the V1 openclip with a new version from grade.

  3. Randomly - in other timelines - where the clip was smart replaced (by versioning the openclip and there is also a layer above the replaced clip the render of the above logo does NOT get invalidated,.

We had this problem now on 2 larger jobs and its a absolute neck-braker

Current solution is to flush renders everytime before export which obviously is completely ridicolous.

So yea let me know, if nobody has submitted it as a bug - I will do it.

Flame 2025.2.1 , MacOS whatever , projectsever , central framestore.

2 Likes

I can confirm this has happened to me on many occasions but I usually fix it and move on and by the time I catch my breath I’ve forgotten that it happened. I haven’t had time to dig in to try to figure out a root cause but it would be a fun thing to investigate one day!

1 Like

Loooong time thing… I tend to work with all segs unrendered bc of such. Anything that needs a rendered status to playback realtime, gets promoted to a comp. A logo w an Action and a Comp shouldnt need to be rendered.

3 Likes

Same. If I’ve got a bunch of timeline renders already done when I update openclips I tend to do it from inside format rather than at the fx ribbon at timeline level and toggle the color management to something else and then back to force invalidate the render.

1 Like

@finnjaeger please open a ticket with our Support team ASAP.

1 Like

Ditto, it’s a constant thing that pops up for sure.

1 Like

wow, it seems I am not alone on this one , will open a case now

Case number 23887723

This is still a major issue for us, I just exported a bunch of timelines to clients in a crunch yet again - leading to wrong/old renders, hell even the burnins show the correct version but the renders arent invalidated.

I am not sure if we can even continue flame anymore for finishing giving this as its extremely embarassing to send wrong stuff out and with hundrets of edits - i cant go into every timeline on every shot update to check wether renders have been invalidated or not.

absolute show stopper for me this thing.

You’re not alone. But, Ive been working around it for years now.

I mean… cmon… you gotta watch down your postings. Sorry, but there is no excuse.

Also… if these hundreds of timelines are such a hassle… why are you rendering all these segments? I do not believe they are all unique frames.

100% agree that this should addressed and fixed tho. Ive lost access to the ADSK account where I had logged this issue a long time ago.

These heated posts about dumping the software are not helpful if you dont even have a ticket in. It IS exhausting constantly submitting tickets and then having to keep track of all these tickets. I know this game and I sympathize deeply.

Tickets submitted, repoduced by flame team and logged as a defect, we did a video, archive and all of that , and yes it takes time and is annoying…

I wish i would have time to watch my renders, there is no way given the current climate and the workload and timeline count to actually do so, absolutely 0 chance, i dont have a solution here at all and its been grinding me down.

this for example is your bog standard beauty retouch -finishing job:

  1. have 100+ Sequences in all the aspect ratios
  2. have maybe 50 actual shots in total
  3. have 5+ flame artists hack away on the shots
  4. have to constantly render all sequences for WIP postings (Daily or every 2 days).

this has become “normal” here which is insane and I agree that its insane, but flame enables us to do this with connected conform, i have all the shots go into all sequences at once using connected segements and openclips, so its doing the update , i can see it updated but then there is some text layer above and its insanely hard to catch that, especially on beauty you end up with such minute changes that even IF you play it all back you would have to have the knowlege of

  1. what shot am I looking at (they can be extremely similar a lot of the times) - ok cool we can render with burnins - however burnin shot version might be inaccurate due to the bug.
  2. even if I have the time - What was the retouch brief even, what was the latest comment, is this REALLY the right version that ended up in the timeline? so i need to compare each shot in each timeline manually to what actually has been rendered. i allready did the QC for each task and stuff in our shot-tracker so i dont want to do it twice.

Regarding re-rendering of segements, its true that the actuall comp work is not beign rendered multiple times however

Repos (action/resize) and timewarps are unique per timeline , and even if they werent - flame lacks any kind of timeline nesting. I already scratched having ML timewarps in my timeline as thats 100% unuseable and takes HOURS or days for projects like this, but in my last job just having maybe 2-3 motion timewarps with motionblur enabled on each sequence took 3 Hours to render all timelines out because i could not trust flame and had to flush renders before export…

Its just the reality we are dealing with and if we cant trust Flame to not render the segment we have in there it makes us look bad

@knhn / @Jeff when you see this kind of issue, please make sure to report them to our Support team. We can only fix issues we know about… It took us less time to fix it than you guys would have taken to fill a Support ticket. But for this to happen, we need to know about these issues.

Thanks to @finnjaeger for going the extra mile on that one!

2 Likes

we are now writing a internal sheet and list of bugs to report and how to properly recreate them and stuff so that all our users are able to self-service create reports thay actualy can be validated and such.

I am very happy about this issue getting fixed in a upcomming update.

1 Like

Very good!

More we know about these issues and better Flame will be.

1 Like