SportsWall IQ is a monitor I built for live sports channels. It watches each channel the way a viewer gets it, raises an alarm when the picture or sound goes wrong, says where the fault most likely is, and tests its own detectors every night.
8 sfrom a dead audio channel to the alarm, in the example below
0 of 17,244planted look-alikes that set off a false alarm
3,037automated tests run before each release
As of 30 October 2026
One-sided audio on a live channel
One Thursday evening a sports channel lost its right audio channel for about an hour and a half. The monitor raised an alarm 8 seconds after it went. The interesting part was the ad breaks: during every break both channels were fine, and the right one dropped again as soon as programme came back.
Programme audio as received
L-25.3
R-89.8
Right channel: digital silence
Right channel lost coming out of a break
Alarm, 8 s later
Escalated to critical after 99 s
Right audio channel, 19:00 to 21:00
19:0019:3020:0020:3021:00
Programme, right channel deadAd break, both channels fineRestored
Six breaks, both channels fine in every one.
The loss, the restore and the first and last breaks (19:13 and 20:31) are to scale. The four breaks in between are spaced evenly here.
Where was the fault?
Before it points at the channel, the monitor checks the other places the fault could be.
CDN and distributionThe ads and the programme came down the same stream by the same route, and only the programme was faulty.Ruled out
NetworkThe fault switched exactly at the break junctions. Packet loss doesn't line up with editorial cuts.Ruled out
The monitor itselfBoth test streams were up, the decoder was delivering audio and the monitoring on every other channel was working.Ruled out
The channel's programme sourceThe fault followed the programme exactly, so most likely an audio mapping problem at playout or the programme encoder.Probable cause
Incident report
This is the report the console wrote for that incident. I've blurred the channel's name.
Timeline. When the audio went, when the alarm fired and escalated, each break where it came back, and the restore, which happened mid-programme rather than at a break.
Failure domain. Why the CDN, the network and the monitor itself were ruled out.
A black picture, caught in 12 seconds
Mid-morning, one channel's picture went to black. The alarm went off 12 seconds later with a clip attached, and the picture came back 6 seconds after that.
The 12 seconds is deliberate. Programmes fade to black between segments all the time, so the detector waits long enough to tell a fade from a real loss. The nightly self-test is how I check that the wait is set right.
LiveBlack picture
09:42:05
Picture goes black
Alarm, clip attached
Picture back
24 hours of ad breaks on 12 channels
On Friday 16 October I let it grade every ad break on 12 public sports channels for a full day: how each break started, what ran in it and how it came back to programme.
1,493ad breaks
2,934minutes of break time, about 49 hours
1 in 7
breaks cut away while someone was still talking, measured at the real cut in the recording.†
88%
of the adverts were repeats. One 15 second promo ran 159 times.
Half
the breaks had no advert in the feed I was watching, just a holding slate. 24 hours of it.*
227
breaks where the picture and the sound cut at different moments.
Picture
Sound
* Many FAST platforms insert adverts per viewer, on top of that slate. I tested two of the channels with four different TV identities and all four got the same slate the monitor saw. What a signed-in app inserts after that, I can't see.
† This page first said 4 in 10. That figure came from a flaw in how my software graded the cut: it timed each cut from the moment it saw the ad cue, which is often seconds away from the real cut. I found it, fixed it and measured the same day again at the cut the recording shows: 173 of 1,244 measurable breaks (14%). The other figures on this page were checked the same way and stand.
How I know the detectors work
Every night at 02:00 it takes short recordings from each channel and plants faults into them: black, freeze, silence, one dead audio channel, total loss. It also plants things that look like faults but aren't, such as dark scenes, fades, held pictures and quiet moments. Then it scores itself on recordings it was never tuned on. A look-alike should never raise an alarm.
Fault plantedCaughtRate
Black picture7,614 of 7,614
100.0%
Dead audio2,537 of 2,537
100.0%
Picture and sound lost2,537 of 2,537
100.0%
One audio channel dead5,066 of 5,076
99.8%
Frozen picture not claimed yet2,377 of 2,406
98.7%
Look-alikes that raised an alarm0 of 17,244
0
From the server's self-test: 14 held-out nights, 12 channels, as of 30 October 2026. Rates are rounded down.
Frozen picture is still below where I want it. The misses I've checked were a still graphic with live sound underneath. The monitor waits 60 seconds on those on purpose, because they're usually a scoreboard or a holding slate, and the planted freezes were shorter than that. When I planted the same ones again as longer freezes, every one raised the alarm.
There's no single overall percentage. Each type of fault has to reach 99% on its own, at 95% confidence, before I claim it. The ones that haven't got there say so. Today's numbers are on the live status page.
How it works
1Public feedsHLS manifests and segments, the same as a viewer's player fetches
2ProbeChecks the manifests, decodes segments with ffmpeg and measures picture and sound every second
3DetectorsBlack, freeze, silence, one-sided audio, loudness, captions, ad breaks
4ArbiterUses test channels, the CDN path and break timing to decide where a fault is, or to drop a false alarm
5IncidentTimeline, clip, probable cause and confidence, sent to the console, alerts and reports
Every night the self-test runs these stages against planted faults. Machine learning models run in shadow until the results justify switching them on.
No language model decides what's a fault
Detection is measurement and rules that can be checked line by line.
Machine learning in shadow first
Models run alongside the rules and only go live on a channel once the evidence supports it. Break detection is live on 3 channels so far.
Alarms come with an explanation
When it started, how long it was held before alarming, when it escalated and the likely cause, with a clip.
Tested before every release
3,037 tests on my Mac, then the full suite again on the Linux server, before anything is deployed. A rollback image is kept every time.
Python
ffmpeg
SQLite
hls.js
Docker
Whisper
What it doesn't do yet
It watches from the outside. It sees the channel's own feed, not what a signed-in app inserts for each viewer.
Frozen picture is below 99%. I won't claim it until it gets there.
Causes are probable, not proven. It can't see inside anyone's playout, so it says "probable" and shows how it got there.
It's one server, built by one person. It hasn't been run by a team or at a broadcaster's scale.
It's tuned on public FAST sports channels. Other kinds of content would need their own nights of testing first.
About me
I'm Guilherme Loureiro, a broadcast operator in master control in London. I built SportsWall IQ in my own time, using AI coding tools, because the question we ask all shift in MCR is whether what we think went to air actually went to air.
If you work in live sports video, I'd be glad to hear how you'd have handled the one-sided audio fault, or what you'd check first.
