A station site should know if it is on air
A station has a real-time state at every moment: who is presenting, what is playing, whether the signal is up. Almost no station website reads it.
3 min read
In short
How do you show now-playing and on-air status on a radio website?
Read it from the stream server rather than maintaining it by hand. Streaming servers expose a status endpoint with current track metadata and listener counts. Proxy that endpoint through your own application so browsers never hit the streaming origin directly, cache it for a few seconds, and derive on-air state by combining it with a schedule held as structured data.
The usual shape, and why it decays
A station site is typically built as a brochure with a play button attached. The schedule is an image. The presenter pages were written once. The player is an embed pointing at a stream URL that will change without warning when the station moves provider.
Every one of those is a thing a human has to remember to update, and the failure is predictable: within a year the schedule image is out of date, and listeners stop trusting the site as a source of information about the station.
Make the schedule data, not a picture
Shows, slots and presenters as records, with the rules for what counts as on air held in one place. Once they are records, three things that were separately maintained collapse into one: the published schedule, the presenter archive, and the strip that says what is on right now.
This is also the difference between a site that answers a listener’s question and one that shows them a JPEG they have to interpret.
Proxy the stream status
Streaming servers expose a status endpoint returning the current track and listener count. Do not call it from the browser. Put it behind your own route, so the streaming origin sees one caller rather than every listener, so the URL and credentials can change without a front-end release, and so you control the cache.
Cache for a few seconds. Track metadata changes on the order of minutes and a page does not need per-request freshness. The proxy is also where you decide what happens when the origin is unreachable, which is the case everybody forgets.
Say when you do not know
If the stream status cannot be read, the site should say the status is unavailable rather than defaulting to off air or, worse, showing the last known track as though it were current. A station that appears to be playing a song from four hours ago is worse than one admitting it cannot tell.
The same rule applies to the player. When a stream drops, tell the listener the signal is unavailable and let them retry, rather than leaving a spinner.
Weight is the other half
Radio audiences are mobile, frequently on constrained data, and often on older handsets. A homepage that ships a large background video before the play button becomes usable is a station losing listeners at the door.
The play button is the primary action on the entire site. It should be interactive before anything decorative has finished loading.
Questions
Should the browser call the stream status endpoint directly?
No. Proxy it through your own application so the streaming origin is not exposed to every listener, so credentials and URLs can change without a front-end release, and so responses can be cached for a few seconds.
How often should now-playing update?
Every ten to thirty seconds is ample. Track changes happen on the order of minutes, and polling faster adds load without adding information.
Related
- Broadcast systems
A station’s website should know whether the station is on air. Most do not.
- Performance and cost
Performance work that ignores the invoice is half the job.
- Khendo FM
A radio station whose website is part of the transmission rather than a poster for it.