Playback records that survive offline periods.
Preserve useful playback evidence when connectivity is unreliable.
Where this work fits
The schedule said what should play. Reporting needed to know what did play, including when a device lost its connection or a prayer interrupted a track. Sending each record immediately was not always possible.
I tracked actual playing time, excluding pauses and interruptions, and retained unsent records in a file-backed queue. A restart could reload that queue. Successful delivery removed the sent batch, while a failed send left it available for another attempt.
Keep the record through a lost connection
Records stay on the device during an outage. When the connection returns, delivery resumes. A failed attempt keeps the records available for another try.
Keep the record until delivery succeeds.
Removing a record when sending started could lose it on failure. I retained unsent records on the device and removed the sent batch after success. Monitoring had a related timing problem: it needed to allow for delayed evidence before treating an expected event as missing.
The skills behind the work
- Python
- Implement device-side or service-side processing and reliability behavior.
- Persistent queues
- Retain unfinished delivery work beyond a temporary disconnection or restart.
- Acknowledgments
- Distinguish an attempted send from a batch the receiving side has confirmed.
Unsent playback records could survive a restart and travel when connectivity returned. Monitoring made missed activity easier to investigate, with alert outcomes recorded separately from the detection itself.