Frustrating day in Flame

[allklier]

Two contributing factors:

The have a very large number of developers in Singapore. Presumably more dev manpower than the other apps behind them.

And with a user based this big, and a solid beta program, they get free test coverage that’s an order of magnitude if not two beyond what the other apps can put together.

Lastly, if the app is essentially free, people are complain less if it doesn’t work, or find their own work-arounds. While we all had experience filing tickets with Dwayne, and have pretty good success getting them fixed, it’s a different beast.

[AdamArcher]

@finnjaeger

Linux is no different in this regard, they could still just support a certain machine on windows as well.

absolutely no idea how blackmagic keeps this up tbh, they ported fusion to everything so quickly.

Yes and no. There are not that many Motherboards around that are certified for Rocky Linux (i.e. RHEL) and same goes for non professional graphics cards. I’m talking the manufacturers of the hardware, not Autodesk.

Sure. Autodesk could certify hardware but it would not be quite as easy for support to push back against someone who says “But all my hardware is certified for Windows”.

[allklier]

A temporary road block. The devs are not allowed to spend anymore time on this, because I’m using a non-certified config, and the Dell workstation I have is no longer certified either.

I have a bit more testing to do, and will source a certified config to see if I can replicate it there so we can re-open the case with better arguments. Not quite giving up yet.

I do understand ADSK’s policy on that. And if you make a policy you have to stick to it. But it can also be really frustrating at times. Especially if you sit in a gray area, where it’s likely not hardware related but in their code, but because it’s all gray, you make a losing argument.

That’s at least the second time, where there was a chance of finding a software bug and making a better product, that wasn’t looked into further. The other one is the NVidia driver install on Rocky 9.3. Found early, and the best we still have is acknowledgement that sometimes it fails, and you just have do it again.

In a complex app like Flame, reproducing a failure on another system is non-trivial, because there are so many small variables (like which viewer config you may have used) that don’t seem relevant at first. There are times where it’s best to debug on the failing system to avoid these ambiguities. But that doesn’t always scale well.

These are well known questions. Back in early 00s while at HP and working on LTO drives and libraries, I was the product manager and software architect of HP Library & Tape Tools (still exists I believe). It is the utility field engineers use to upgrade firmware, and diagnose failures. One of the innovations (at the time) was that we build an error report that captured all the logs, screenshots, etc. that could be sent back to the factory. Precisely to solve the problem of being able to see as much as possible of what it looked like on location, rather than relying on Swiss cheese emails/tickets. Very similar to today’s ADSK collect and transfer log script.

Getting the bottom of this type of stuff and not giving up is an occupational hazard or some form of PTSD for me.

In fairness to ADSK, I also had a heated discussion with Walmart’s IT director about why our field engineers couldn’t guarantee replacement drives to have a certain fix, because we didn’t implement a serial number break on the inventory, and he being unpleasant finding this unacceptable, as he knows exactly how many pencils each of his employees uses. So I guess there are always dgrees in this area.

</soapbox>

[Ton]

That memory leak has been there for ages and it’s known. I (and plenty others) have reported it (search the feedback). It’s one reason I like working on my MacStudio… vram for days… (until I need ML stuff… then meh…) … When I’m on linux, I’ll tend to restart the software every hour/ 30 mins or so to flush vram… upgrading to RL9 this week, maybe that helps.

[Jason_Kalinoski]

@allklier

… and crashes. Consistently.Which is now the question for the devs, who weren’t able to reproduce it. But they may not have had my typical viewer configuration.If that is the missing link, my guess is 2-up view, some code gets skipped that releases the VRam either for the image schematic thumbs, or something along those lines. Not enough to kill Flame on a short-form project, but it piles up quickly.

FWIW, I tested this today on the 16bit timeline versions that were crashing on Friday and had no issues. That being said, I had made quite a few changes before making duplicates and rebuilding in 10bit so maybe I had already deleted the offending node/clip/bug…who knows.

Interesting observation about the viewer config, I usually work in 2up (schematic, result) or 3up (schematic, result, scopes) as well, so we’re similar there. At least I can try changing viewers if it happens again so thanks for passing that along.

I guess we could try working in a single view like all the old school folks, but I would probably give myself a seizure.

[allklier]

Well as the video games of old used to say: Time Extended.

The ticket got closed, but then re-opened after it was linked to a similar report from someone else. And since then it has been confirmed and reproduced.

Now tracked as bug FLME-68999.

Thanks to the tireless ADSK support agent who stayed with me on the case and made this happen.

And to everyone - support cases help, sometimes they don’t result in immediate help, but can become a sleeper puzzle piece. So if you encounter problems, take the time to file a ticket.