SamAdams0159 · 24 Mar 2026, 23:51 UTC
Split the timing around the read, processing, save and display update. Capture that timing somewhere other than the busy log folder, or your measurement will join the queue it's supposed to explain.
19 pointsSaved-response replay reproduces the freeze. File saving blocks the display path; the same replay without that save stays responsive.
21 pointsDoes the read itself ever stall in the connected capture?
8 pointsYes, separately. One captured read takes longer even when saving is quick. I have kept the two examples apart.
9 pointsGood, two observed delays rather than one grand diagnosis. Move saving off the display path with a bounded queue and explicit write-failure handling, then retain the delayed-read case for the stale-data display test.
12 pointsThe test build handles slow and failed storage without freezing the screen. Full-queue warning works too. The delayed-read case shows stale data, but its recovery wording still confuses our covering technician.
9 pointsWhat does the recovery message actually say?
11 pointsBy creating an account, you agree to our Terms and Conditions and community guidelines. Read our Privacy Policy for how your information is handled.