Two groups eventually ask what you played: the organisation collecting royalties, and the sponsor who paid for a spot. Neither accepts a verbal answer.
What gets recorded
Play history is written automatically to a local SQLite database as tracks play. Each entry holds the file path (unique and indexed), title, artist, first played, last played, play count, and total time played accumulated in seconds.
That last field is more useful than it looks. Play count treats a track skipped after five seconds the same as a full play. Total time played does not.
Reviewing it
The history view sorts by last played, play count or total time, all descending. Last played is the default, because the most common question is "what went out this morning".
Compliance, not just history
The airplay compliance window goes further than a log. It reports plays per hour, category performance against rotation targets, and an overall compliance percentage — telling you not just what played but whether it matched the format you designed.
It also runs export file checks and flags log-gap hours: periods where nothing was recorded. A gap usually means the machine was off, the application crashed, or something was playing outside the system. All three are worth knowing before someone else finds out.
Why gaps matter more than they seem
A missing hour in a royalty submission is not a rounding error. Depending on the collecting body, an unexplained gap can invalidate a return or trigger a query you then have to answer months later, from memory.
Finding those gaps the same week is a very different task from finding them the following quarter.
Keeping it honest
The database lives in your local application data folder and is written with WAL journaling for durability under sudden shutdown — the failure mode that actually happens in a studio, where machines lose power rather than being shut down politely.
Clear history exists, but think before using it. It is the only record you have.