I was going to work on a way to monitor our web stream and fire off an email or text to our tech team whenever it detected an outage or silence for an extended period of time so that they could respond quickly. It occurred to me, however, that rather than have another server constantly connected to our stream, it might be nice to have that service come from something that’s already always listening.
This is clearly not something that’s within Spinitron’s purview, but I thought I would float it anyway because it might be easy enough to implement (I have no idea if silence detection could be worked into how ACR functions), and I could imagine stations might even pay for it as an add-on. Just a thought!
I’m pretty sure I don’t want to get into the service monitoring business. But in case anyone reading this thread does I can maybe help your elaborate some basic tech specs?
Do you want to monitor your webcast only? I would think so because monitoring and alerting transmitter output is (iiuc) a solved engineering problem.
Monitoring for dead air isn’t really part of monitoring a webcast service. It could be incorporated in a webcast monitor but it won’t work if the webcast itself isn’t up. That might be acceptable or not, it’s up to you.
Most stations have an arrangement with stream encoder at the station and a remote stream server that has the bandwidth for many client stream connections. I would consider adding monitoring and alerting there rather than somewhere downstream of the stream server. What do you think @dklann ?
For those of you using the Ark archive service we provide, you get a retrospective view of the recordings the archive stream server has made using a URL like this ark3.spinitron.com/cgi/avail/?station=STID replacing the STID with your own station ID, which is usually the same ID as in your other Spinitron URLs. This is not a real time monitor since it updates once an hour. And there is no alerting. But the outages in these graphs usually indicate a problem with encoder or stream server or connectivity among them and/or our recorder.
Hey @tom, I concur – monitoring the stream for dead air is best handled in two places: at the stream server itself, and at the station device encoding the audio and sending it to the server. Seems like implementing it at Spinitron is too far “down the line” from the stream itself.
Stations that host with BT&D have the option of email alerts when the stream server notices that the station’s encoder disconnects from the server.