rdio-scanner turns SDR recordings into a browser based scanner

The unit of work is a transmission, not a stream of samples

rdio-scanner ingests and distributes audio files generated by various software-defined radio recorders, and the key technical requirement is stated plainly in the compatibility section. It works with any radio recorder, as long as they can create audio files separated by conversations or transmissions. That single condition decides compatibility before any code runs. The tool does not tune frequencies, demodulate signals or decide what is a talkgroup. It deals in files that somebody else has already split, and the value it adds is indexing, storing and presenting them. The interface tries to reproduce the user experience of a real police scanner while adding its own touch, and the delivery is a web app you can listen to on any modern browser. So the division of labour is clean. The recorder handles the radio, and rdio-scanner handles the archive and the browsing experience. A listener using the web app sees something that behaves like the scanner they grew up with, which matters more than it sounds, because the whole appeal of monitoring amateur and public safety radio is the scan itself rather than a directory of files.

Two integration paths, and a compatibility table you can check

The recorder integration is offered in two forms, and the README gives a table of which recorders support which. The API column and the Dirwatch column. Trunk Recorder supports both, RTLSDR-Airband supports directory watching only, SDRTrunk and voxcall support the API, and ProScan and DSDPlus Fast Lane support directory watching only. The names of the two mechanisms are the whole architecture. An API integration means the recorder tells rdio-scanner about new files, which is precise and avoids the tool having to watch a filesystem. A directory watch means rdio-scanner polls a folder that the recorder writes into, which is simpler and works with recorders that have no such API. For someone choosing a recorder, the table is genuinely useful, because it is the difference between a recorder that integrates cleanly and one that only works by convention. It also sets the boundary of what rdio-scanner can do on its own. It cannot control the radio, cannot retune a receiver and cannot merge two recorders into one archive without doing the file splitting itself, which is precisely the job it delegates.

Precompiled archives per platform, plus a container image

Installation is a download and an extract, and the README is emphatic that you get the latest precompiled version from the official repository, with a link in capitals. The releases tab carries archives per operating system and architecture, and the archives carry the version in the filename, with the build metadata that produces them:

app := rdio-scanner
date := 2026/05/16
ver := 7.0.0-dev

The listed builds cover FreeBSD on amd64, Linux on 386, amd64, arm and arm64, macOS on amd64 and arm64, and Windows on amd64, all carrying the v7.0.0 version tag. The procedure is four steps. Download the archive, extract the contents somewhere on your computer, run the rdio-scanner executable, and then access the administrative dashboard to finalise the configuration. The dashboard step is where you point the tool at your recorder output and set up your system, and the README notes that more detailed instructions are in the rdio-scanner.pdf file shipped inside the precompiled archives. A Docker image is also published, with a new version generated for each release, and the Makefile shows how the build works behind it. The build compiles the Go server with GOOS and GOARCH set for each target into a dist directory, and a pandoc step converts the documentation, the web app guide, the FAQ and the changelog from markdown for shipping inside the same archive.

The licence splits the project in two

This is the part to read carefully before you build anything on the project. The code is licensed under the GNU GPL, and the HTTP REST API is fully available for all uses. However, the WebSocket API is described as a proprietary service provided exclusively by Saubeo Solutions for its native applications and the integrated web application, and the README says this restriction supports the commercial model that funds the project's development. Self-hosted deployments can use the HTTP REST API without limitation, but access to the WebSocket API in self-hosted instances requires a licence agreement, with the details in an API_ACCESS_POLICY.md file at the repository root. So the project is not uniformly GPL in practice, even though the source is published under it. Anyone building a self-hosted tool that needs live streaming rather than polling has to engage with the vendor, and anyone who reads only the licence badge will get this wrong. The Makefile header shows the GNU General Public License version 3 notice with a copyright line for Chrystian Huot, which is the author identity behind the Saubeo Solutions name. A second administrative file is worth noting, the ICAA.md, an Individual Contributor Assignment Agreement that contributors agree to by submitting a pull request, which tells you contributions are assigned rather than merely accepted under the same terms.

Where the boundary sits and who the tool is for

The project's audience is narrow and the README is honest about it, with a topics list covering radio, scanner, SDR and firefighter alongside police. The native mobile apps on the App Store and Google Play extend the same interface to a phone, which is how a monitoring habit actually forms, since a scanner experience that only works on a desk is not a scanner experience. Support comes through two channels, a GitHub wiki and GitHub Discussions. The limitation that matters most is the scope of the tool itself. It does not receive radio, it does not demodulate, it does not do automatic voice recognition to identify talkgroups or transcribe transmissions, and it does not replace a recorder. If your problem is that nobody is listening to a frequency and nobody wants to run the receiver, this project does not address that. If your problem is that the recordings from your receiver are scattered across directories and hard to browse, that is exactly the problem it solves. The alternative approaches differ in kind. Running the recorder's own web interface gives you less of the scanner feel and no cross-recorder archive. A general purpose media server gives you playback without talkgroup organisation or the scanner metaphor. The distinctive value here is the archive and the presentation, and that is what you are buying.

Editorial conclusion

rdio-scanner is worth adopting if you already run a software-defined radio recorder and want a single place to browse, replay and distribute what it captures, because the recorder compatibility list is broad and the archive format is shared. It is the wrong choice if you need its WebSocket API in a self-hosted deployment, since that path requires a licence agreement with the vendor, and it is a poor fit for a monitoring site that wants the HTTP REST API only, because the streaming interface is the part the project reserves. Verify first that your recorder can either expose the directory watch mechanism or drive the API, that the audio files it produces are split per transmission as the tool requires, and that the API access policy matches the deployment you intend. The last push was on 2026-08-27 and the newest tagged release is v6.6.3 from 2022-11-25.

Frequently asked questions

Official sources

1. chuot/rdio-scanner on GitHub
2. Issues
3. License: GPL-3.0
4. README
5. Releases