Elio Antoine logo
← BACK TO WRITING
Software / Data integrity

RadioFinder.ca: A Directory That Keeps Checking Its Own Data

Ownership verification, continuous stream monitoring, and why a radio directory that stops checking its own listings is finished the moment it launches.

Elio Antoine · Founder & Developer

Every radio directory site has the same failure mode. A crawler finds stream URLs somewhere on the internet, pulls whatever metadata comes with them, and lists it. Nobody checks if the stream still plays. Nobody confirms the station is still on air. A year later, half the entries are dead, and the directory has no way of knowing which half.

RadioFinder.ca was built to solve a different problem than "list radio stations." The real problem is: how do you keep a directory honest over time, when the data underneath it changes constantly and nobody who built the list is still watching it?

Ownership has to be proven, not asserted

The feature that makes RadioFinder different from a static list is that broadcasters can claim their own station listing and take control of it. That sounds simple until you ask the obvious follow-up question: what stops anyone from claiming any station?

The naive answer, a logged-in user clicks "claim" and they're now marked as owner, fails immediately. It has no relationship to whether that person actually runs the station.

The real answer treats a claim as a verification problem rather than a form submission:

One thing this process surfaced along the way: a flag in a database is only as reliable as the event that set it. An early data cleanup pass had marked a batch of accounts as verified in one bulk operation, technically true in the database, not true in reality, since none of them had gone through the actual verification step. It's a small case of a bigger principle: a boolean is a claim about the world, and it's only trustworthy if something real produced it.

A live stream is a status, not a fact you check once

Directories that scrape once and list forever have no way of noticing when a station goes dark. RadioFinder runs a recurring check against every listed stream and tracks whether it's currently reachable, when it was last confirmed, and how long it's been down if it isn't. That reframes "is this station still broadcasting" from a fact recorded at listing time into something the system continuously re-verifies, closer to how you'd monitor uptime than how you'd maintain a static list.

Not every stream speaks the same protocol

Two compatibility gaps came up in practice. Some broadcasters serve their audio as an HLS playlist rather than a direct stream file, which a standard browser audio player can't handle on its own. The player has to detect that format and route it through a dedicated HLS library instead. Separately, some stations still run stream servers over plain HTTP, which modern browsers block when the surrounding site is served over HTTPS. Both needed the player and delivery layer to adapt to the broadcaster's setup rather than requiring every station to modernize their own infrastructure just to appear in the directory.

Findability matters as much as accuracy

None of the above matters if the right station doesn't surface when someone searches for it. A review of real search performance data showed listings underperforming on exactly the kind of intent people were searching with, queries about listening live, not just the station's name, along with genre categories that were too narrow to match how people actually describe music. Both were corrected based on what the data showed people were actually looking for, not assumptions about what they'd type.

The underlying idea

A directory that scrapes and lists is finished the moment it launches. A directory that verifies ownership, monitors its own data, and adapts to how broadcasters actually stream is never finished: it's a system that has to keep being right. That's the harder problem, and it's the one RadioFinder.ca is built around.

Data Integrity Verification Systems Stream Monitoring SEO Radio Technology