SaraBarnes0548 · 4 Sept 2026, 20:18 UTC
Measure the read and the write separately in the diagnostic app. I'd start with elapsed timings kept in memory for a short controlled comparison, so the measurement itself doesn't add another file write to every update.
14 pointsThe developer can do that; our current timestamp is written only after both operations finish
8 pointsThat explains why the existing log can't separate them. Ask for display-update timing too, because the data might arrive promptly and then wait behind another job on the screen's thread.
6 pointsIs the folder local or shared? Our diagnostic utility looked like it had lost the controller whenever the network share stalled. Different machine, same wonderfully misleading symptom. We only found it after timing the output stage.
-5 pointsWorth checking, though even local storage can stall. I'd avoid moving everything around until you've captured which stage accounts for the pause; otherwise you may remove the symptom without learning what delayed it.
15 pointsShared folder. I've requested separate timings and a visible age for the last successful read
12 pointsThe age display will help people interpret a pause. If they later move logging to a queue, ask what happens when that queue fills; an endless memory backlog would just postpone the problem.
14 pointsDocument what a stale display means for the person using it, including how they obtain current diagnostic information. Since this is separate from cell control, its frozen value should not quietly become an operator's assumed live status.
22 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.