On Air Widget specs

Let’s spec a new widget called the On Air Widget. It would probably display something like

  • recent spin(s?), if any
  • currently on-air playlist title and DJ, if any, and if not, the recently ended one?
  • if no current playlist, the currently scheduled show title and DJs, if any
  • if none of the above, next show airing soon, if any
  • some default fallback text if none of the above, e.g. station branding

There’s a lot of detail, branching, and timing conditions that can complicate this. Maybe if we work together we can design something that will satisfy some stations. It needs to be simple enough that I can write it and y’all can easily use it but sophisticated enough to say something useful about what’s on-air now no matter what’s going on in your station’s Spinitron database.

Each station’s landing page on spinitron.com already does something a bit like this. So we can think of the widget as being like a condensed, two-or-three line summary of that. It might be useful to refer to such a page when discussing this new widget’s specs.

You’d be able to deploy this new widget like you do the existing ones. For example, the testradio.org home page has the Now Playing and Upcoming Shows widgets.

This On Air Widget would be very helpful to us. We would use this condensed version of On Air on our homepage. How 'bout these elements?

Title is “On Air” Time (the track started) current track track that played immediately prior to the current track. Not a must have, could make the widget too large? link to View Full Playlist - this would go to the landing page Tom referred to

If there is no song recognized, the Program name would be featured. This Program name would need to pull from the Schedule. We have many talk shows where we don’t create Playlists (very small staff, don’t have the bandwidth to create blank playlists for each talk show each week). Also, when a song isn’t recognized by the software, the Program name would display in it’s place.

1 Like

Hi @KMREPD, thanks for joining the forum.

I still think we should use the playlist title, if there is a current playlist, and use the currently scheduled show if there is no current playlist, because it’s quite common for program substitutions to happen that never find their way into the schedule in Spinitron.

To say it in other words: if in Spinitron there’s a current playlist and there’s a currently scheduled show and they have different titles, which is more likely to describe what’s really happening on your radio station?

We can display one spin by default and allow two or more as an option like we do now, see num here.

I think my initial sketch of the specs are largely compatible with yours. You agree?

Yes, agreed on the use of the Playlist and use currently scheduled show if no playlist. That does indeed cover more scenarios. Thanks for the info on displaying number of spins - 1 by default sounds good, with the option to show 2 or 3. What do you think of the link to View Full Playlist in the widget?

Yes, it makes sense and the stations that don’t want it can hide it with a style rule.

Tom, we frequently have sports broadcasters on air. When they tell us at the start of the week when they will be on, we cancel those DJs shows’, but don’t delete them from the schedule in spinitron. Would it be possible for them to put a episode title or something of the sort in so that the now playing widget would say that a sports broadcast was currently underway?

Hi Jonah, thanks for joining the forum.

For each such sports preemption you should create a playlist and check the Display as a future public playlist checkbox. This will make the playlist visible in your public calendar so that people can see the upcoming program change. There’s no need to put any spins in it but I could be nice to have a playlist title and episode description that says what’s going to be broadcast in that time-slot. The playlist can be a one-off or associated with a show, either way works. Create such playlists as part of the routine start-of-the-week process you described.

If you do that then the widget we’re sketching out here will display the playlist information (title, episode description) when it is on-air and has no spins.

Tom, this is good to know! When you describe this on-air widget, could it be integrated with the metadata push? I would love to integrate an RBDS with encoder with our transmission system, but haven’t figured out how to display talk shows and sports broadcasts. This widget seems to get closer to an ideal solution.

No. Metadata push is an entirely different subsystem in Spinitron. We have attempted in the past to build features into it to push messages that aren’t about spins but those efforts were abandoned.

I see. If this widget is built, could you provide an api endpoint for this “now playing” field (music, show, station ID) and then I could write my own script to push that to the RBDS?

I don’t think the API would be the right place for it.

Bear in mind that metadata push is event-driven on the Spinitron servers: at a given moment (the spins timestamp or as soon as the spin is inserted into the DB) it sends a message out.

If you wanted to build something like you describe based on data from the API, I don’t think you would want to just poll it every few seconds for a compound string like in this widget, detect a change, and push an RDS update. The API has information about future events, e.g. when the current playlist ends, what’s the next scheduled show and when, so you can schedule push events based on that.

In any case, formatting for RDS should probably be different from formatting for a web widget since RDS is text string only and extremely short.

As a hybrid News and music station, this would be enormously helpful to have at least the Show title pop up on RDS and Now Playing when there has been no new spin detected for 7 or 8 minutes. Its a big “is this working” question mark when nothing new has been detected. The RDS api push for us, while not perfect is simply excellent.

1 Like

Hi Cambridge Community Radio, thanks for joining the forum.

Pushing to RDS (and things like that) is a different technical problem to solve from a widget that you can put on a web page.

With the widget, Spinitron respond to requests from browsers as it receives them. So Spinitron can answers using whatever information it has at the moment that it processes the request.

With RDS, Spinitron has to push a message to the RDS encoder to update the display. Spinitron is not responding to a request, it is initiating the sending of a message. This needs to be triggered by something. At present all we have for triggering such sending is new spins.