My FR5 diagnostic replay looks disconnected when I export a large log from the same folder. The display freezes, then several readings appear together. I added detailed logging recently.
This application only displays diagnostics. Another person will maintain it after me, and I do not want to leave them an 'offline' warning which actually means my file handling is slow. Where should I put timing checks first?
Time the receive step, file write and display update separately, using a monotonic clock for durations so a clock adjustment does not confuse the comparison.
Get the file write out of that callback. A busy disk shouldn't make the screen sit there pretending nothing has changed. But cap whatever queue you add, or you'll just build a different mess.
I'd let routine diagnostic lines drop before letting the queue eat all the memory, but show how many were dropped. Otherwise support gets a very convincing incomplete log.
That policy depends on the log's purpose; if particular events must be retained, distinguish them from high-volume diagnostic samples and make a recording failure visible.
I tried a bounded queue in the replay application. The display continues while the writer falls behind, with an increasing age on the saved-log position. Still deciding which samples can be dropped.