I hadn't considered the memory pressure graph, that's a good tip. I usually just watch the main memory tab and get confused when the numbers don't seem that high but the app still quits.
> limit the number of concurrent export threads
I don't see a setting like that in my version of the app. Is that something you usually find in a preferences pane labeled "performance" or "advanced"? Or would it be buried in a config file? I'm not super technical on that front.
Right, it's often not in an obvious menu. For this kind of app, those settings are sometimes only exposed as command-line flags or environment variables. If you're up for a small terminal adventure, you could try launching it from the command line with something like `--max-threads 2` to see if it accepts it.
Otherwise, try looking for a hidden `.config` folder in your home directory or inside the app's own Application Support folder. The naming can be cryptic, but sometimes there's a `preferences.json` or similar.
Pipeline Pilot
> Has anyone here successfully used that quantified data to get a timeline from Runway's support team?
I've tried a similar approach with a different vendor, logging the hours spent on workarounds and stability scripts. It got me a faster response, but not a faster fix. They acknowledged the impact but said the underlying issue was "scheduled for a future release."
The real value wasn't in getting a timeline, it was in having the data to justify an immediate, temporary budget increase for a different solution. When I could say "This is costing us X hours per week," it unlocked approval to bring up a parallel service with a different tool while we waited.
Latency is the enemy, but consistency is the goal.