Live operations / 8 min read
When the live presenter disconnects: designing a clean return to AutoDJ
A live show is only half the workflow. The other half is what the station does when the encoder stops, the presenter loses connectivity or the source disappears without a tidy sign-off.
An external live broadcast starts when an encoder connects to the station’s source endpoint. The operationally important moment often comes later: the connection ends and automated programming must resume.
That transition should be designed, monitored and rehearsed. It should not be left to the hope that the streaming server will “work it out.”
Define the source states
A station needs more than a red or green light. Useful live-source states include:
- Awaiting source — credentials and endpoint exist, but no encoder is connected.
- Connected, no usable audio — the network session exists, but the audio path is silent or invalid.
- Live — the external source is active and supplying acceptable audio.
- Disconnecting — the source has ended and the platform is moving back to automation.
- AutoDJ active — automated programming is again supplying the public stream.
- Degraded — the intended path is unavailable and a fallback is active.
Clear states help operators distinguish a presenter who has not connected from an encoder that is connected but not transmitting useful sound.
Keep authentication and handover separate
Source credentials answer “May this encoder connect?” They do not answer “Should this source now replace AutoDJ?”
The platform should validate the source, associate it with the intended station and make the transition visible. If credentials are wrong, the presenter needs a precise connection error. If credentials are accepted but the station is not ready for handover, the operator needs a different explanation.
Rotating credentials should invalidate the old secret predictably without exposing it in logs or agent responses.
Decide what counts as a disconnect
A tidy presenter shutdown is easy: the encoder closes its connection and the platform resumes AutoDJ.
Real failures are messier:
- Wi-Fi drops;
- a laptop sleeps;
- the encoder process freezes;
- a mobile hotspot changes networks;
- packets stop while the TCP session appears alive;
- audio becomes silent;
- the source reconnects repeatedly.
The recovery policy needs timeouts and thresholds that balance continuity with false failover. Returning to AutoDJ after an unrealistically short gap can interrupt a momentary network wobble. Waiting too long leaves listeners in silence.
There is no universal timeout. Test it using the station’s source clients and network conditions.
Make AutoDJ ready before the live show
Failover cannot recover to a source that is not prepared.
Before a live programme begins, verify:
- AutoDJ is enabled;
- the queue or schedule can supply the next item;
- required media is available;
- the public stream is healthy;
- the live credentials and endpoint have been tested;
- the operator can see which source is on air.
The safest live workflow keeps automation ready in the background, even though it is not the active source.
Resume intentionally
When the live source ends, the automated path should return in a known state.
Questions to decide include:
- Does AutoDJ resume the item that was interrupted?
- Does it advance to the next item?
- Does it follow the wall-clock schedule?
- Is a station ident or transition item inserted?
- How are track history and royalties logs represented?
- What happens if the source reconnects during the recovery window?
A station that runs strict timed programmes may need different behaviour from a continuous music station. The recovery rule should match the editorial model.
Monitor the listener path, not only the source socket
A connected source does not prove listeners can hear it. A robust check follows the delivery path:
- source connection accepted;
- valid audio received;
- stream service serving the station;
- public MP3 or AAC endpoint reachable;
- player able to receive audio;
- metadata and artwork updating.
Likewise, “AutoDJ process running” does not prove that the public stream successfully returned after the presenter disconnected.
Synthetic listener checks can read a bounded portion of the public stream and confirm that audio bytes are arriving. They should be rate-limited and designed not to inflate audience analytics.
Rehearse failure, not just success
A pre-launch test should include:
- Start AutoDJ and confirm public playback.
- Connect the external encoder.
- Confirm the on-air source changes visibly.
- End the encoder normally.
- Measure the return to AutoDJ.
- Repeat by cutting the encoder’s network unexpectedly.
- Reconnect during the recovery window.
- Rotate credentials and verify the old secret fails.
- Test MP3 and AAC listener paths independently.
- Review the event history after each scenario.
Record the expected and observed transition time. If listeners hear silence, repeated audio or an abrupt burst, treat it as a failed rehearsal even if every process reports healthy.
Explain the transition to operators
An operational event should read like:
External source disconnected at 20:58:14. AutoDJ became the active source at 20:58:17. Public MP3 and AAC checks passed. No operator action required.
That is much more useful than “source offline.”
When recovery fails, report the failed layer and the next safe action. Avoid burying a live incident under infrastructure terminology that a presenter cannot act on.
The continuity principle
External live broadcasting is not a separate island inside the station. It is a temporary source within one continuous listener service.
The platform should know when the source connects, when useful audio begins, when the source disappears and whether automation has genuinely reached the audience again.
SGNL Desk uses external broadcasting software or hardware rather than a browser microphone studio. The live-source workflow and AutoDJ return are described in live radio broadcasting software.