I DJ by looping a track and layering more over it. For a while my stream named only the first one. Chat got song 1, then nothing, while the rest of the build played on top. When I dug in, I found two separate causes, and one of them had been quietly broken for about five weeks.
On October 20 the new detector beat the old one in a side-by-side test. The same evening it went blind for three hours, and the old one covered for it. That's why the old one is staying.
How I actually mix
My transitions are long. I set a loop on the track that's playing, bring the next one in on its channel fader, and let them run together. Then I loop that one and bring in a third. When a track has done its job, I EQ it out and pull the fader down shortly after, so an EQ'd-out song lingers in the mix for a few seconds after you stop hearing it.
The decks report what they're doing over their network feed: which track is loaded, where each fader sits, whether a deck is looping. The stream reads that feed and posts track names to chat. The broader habit of testing the real thing is in Walk the Room. This post is the specific bug.
Cause one: the safety net had been frozen for five weeks
There were two detectors. The main one decides a new song has arrived when the old song leaves the mix. Beside it ran a smaller watcher I built in July for exactly the layered case. All it did was watch for a channel fader to rise.
That watcher stopped working around September 12. It logged every state change, its logs went to a backend that stalled, and each write blocked its event loop. It stayed frozen for about 37 days before I measured it.
The proof was a positive control. In the same six-second window, the neighbouring devices' broadcasts arrived fine and the watcher's heartbeat was silent.
The part I don't love: a hung log read was noted on September 13. The warning sign was logged once and never followed up.
Cause two: a looping song never leaves
With the watcher frozen, everything fell to the main detector, and the main detector waits for the old song to leave. That works when you mix A into B and let A go. A looping song never leaves. It sits under everything, so the detector kept waiting for an exit that wasn't coming, and the stream stayed on song 1.
A smaller bug lived in the same path. New songs waited in a single 30-second holding slot. If song 3 showed up within 30 seconds of song 2, it took the slot, and song 2 was never named.
Every deck gets its own state
The new detector stops asking which song is playing and tracks what each deck is doing. Every deck moves through these states:
- Cued: loaded, not in the mix yet.
- Incoming: fader up, not confirmed yet.
- Live: confirmed and in the mix.
- Looping: on a loop.
- Out: out of the mix.
A few rules sit on top. A song is named once, after 30 straight seconds in the mix. A newer song never cancels a pending one, so the holding slot can't eat song 2 anymore. A quick flash of the fader never posts.
And a looping deck counts as layered. It is never the headline. Replayed through the new rules, a four-track build with made-up names reads like this:
- Neon Tidewater
- Paper Satellites, over Neon Tidewater ⟲
- Glasshouse Drift, over Paper Satellites and Neon Tidewater ⟲
- Low Orbit Choir, over Glasshouse Drift, Paper Satellites ⟲ and Neon Tidewater ⟲
Shadow mode reported healthy while posting nothing
The new detector ran in shadow mode first, from October 19: watching the decks, recording what it would have said, posting nothing.
Review of the change found two critical issues and five important ones. Each got a test that failed first, then a fix. The change carries 103 tests, 58 of them on the new detector.
One of the critical issues is the one I keep thinking about. In shadow mode, the new detector reported itself healthy. It was also posting nothing, on purpose. If the system had trusted that health signal, it would have muted the old path, and chat would have gone quiet with a green light on. For anything that posts, healthy has to mean it is doing the job.
Side by side, with the decks on
Decks on, both detectors listening, real layers. The new detector caught all four tracks in order. The old one announced one early, missed one and posted out of order.
I cut over on the evening of October 20. The new detector drives chat now, and the next stream is the first full set with it in charge. I'm not calling it proven until it has carried a whole night.
The part that wasn't clean
After one restart, the new detector couldn't hold its connection to the decks. For about three hours of a set, it saw nothing. The old detector was still running, and it covered those hours. A later restart fixed it. I still don't know the cause.
That's the whole case for the fallback. The old detector is worse at layers, and it covered three blind hours anyway.
A booth tech always keeps a second path live
This is one of the oldest rules in live events. Nobody runs a show on one path. The backup playback rig is rolling in sync, the spare mic is already patched, and you keep them live, not in a road case.
It's tempting to retire the old path once the new one passes its tests. I'm keeping mine. The new detector leads, and the old one stays patched in underneath, the way a looping track sits under the mix.
If you are about to try this
- Give every watcher a heartbeat, and compare it with a neighbour. Silence means nothing unless its neighbour is talking.
- Never let logging block the work. If the log backend stalls, drop log lines rather than freeze the job.
- Chase the first weird log line. Mine was written down once and then sat for weeks.
Build it yourself
What it does: reads your decks' network feed and names every track that enters the mix, including the ones layered under a loop. The pieces:
- A feed reader that watches each deck's fader position, loaded track and loop state.
- A per-deck state machine with states like cued, incoming, live, looping and out.
- A confirm timer. A track is named only after N seconds straight in the mix (I use 30). A newer track never cancels a pending one, and a quick fader flash never posts.
- A side list for looping decks. They show as layered next to the headline, never as the headline.
- The old detector, kept as the fallback, with a health check that means "posting", not "running".
How it fits: the reader turns the feed into deck events, each deck's state machine moves on those events, and a small publisher posts the headline plus the layered list when a deck is confirmed. Run it in shadow mode against a real set first, and compare it with the old path track by track.
If you mix this way and your stream has ever been stuck on the first song, tell me how you handled it. I'd like to compare notes.
NoteWritten October 2026, about work from October 2026.