m3u-radio-music-playlists, a scraped and checked directory of internet radio streams

What the repository actually contains

This is a collection of internet radio playlists rather than a program, and the repository top level shows the structure immediately.

At the root there are per-genre files with names like blues.m3u, breakbeat.m3u, chillout.m3u, classical.m3u, club.m3u, country.m3u, disco.m3u, downtempo.m3u, easy_listening.m3u, ebm.m3u, electronic.m3u, eurodance.m3u, film.m3u, folk.m3u, funk.m3u, gospel.m3u, gothic.m3u, hardcore.m3u, hardrock.m3u, hip_hop.m3u, house.m3u, indie.m3u, industrial.m3u, instrumental.m3u, jazz.m3u, jpop.m3u, jungle.m3u and more, with decades as separate files named 60s.m3u, 70s.m3u, 80s.m3u and 90s.m3u. There are also country-specific and language entries such as arabic.m3u, asian.m3u, christian.m3u, deso.fm and france.m3u.

Then there are the combined files, and their naming is where the design becomes clear. There is ---everything-lite.m3u, ---everything-full.m3u, ---everything-checked-lite.m3u, ---everything-full-repo.m3u, ---everything-checked-repo.m3u, ---everything-lite-repo.m3u, ---sorted.m3u and ---randomized.m3u, plus ---everything-full-repo2.m3u.

The prefixes encode two independent axes. The full and lite distinction is about how much was collected, and the checked distinction is about whether the stream was verified as working. The repo suffix means the file was assembled from this repository rather than from one of the upstream sources directly, and the numbered variant of the full repo file is a regeneration artefact that has not been folded into the main one yet.

Alongside those are two directories with names beginning with a plus sign, +checked+/ and +merged+/, and a set of source directories that preserve where streams came from: allradio.net/, all-online_radio/, app_radio-fm/, cue_tree/, deso.fm/, fm_cube/, escuchar.radio/ and allradio.net/, plus _zoo_/ and extras/.

So the data is organised three ways at once: by genre, by provenance, and by whether the entry has been confirmed to play.

The checked and full distinction and why it exists

The most useful thing about the collection is the distinction between a stream that was found and a stream that was verified, and the topics confirm it, with checked, collection, scraped, sorted and updated all listed.

The size difference is large. The README says a newly curated list of playlists contains many, over 500 thousand, checked streams. So the checked set is on the order of half a million entries that were confirmed to be live, and the full set is larger still, containing everything that was scraped.

That gap is the whole value proposition, and it also explains the design of the tooling around it. A scraped internet radio stream URL is cheap to obtain and cheap to lose. The station closes, changes its format, moves to a new host, or starts requiring a referrer, and the entry becomes a dead link that a player reports as a silent failure.

The README has a section on checking for dead links without using code, which is a hint at how this is maintained. Doing that in a browser rather than in a script suggests the checking runs through a hosted workflow rather than a local script, and that the results are committed back to the repository rather than served live.

The consequence for a user is practical. A checked file is larger and slower to load but far more likely to play. A full file is a superset that includes stations that were never reachable or have since gone, which is what you want when you are looking for something specific and are willing to skip through failures.

There is also a per-source view. Because the source directories are kept, a stream that fails can be checked against what that source last published, which turns a mysterious dead entry into a diff. And a source directory that stops being updated is itself a signal, which is a form of quality control the collection inherits for free.

Listening to it, and the tools around the data

The README spends more space on how to listen than on how the data is produced, which is a reasonable ratio for a dataset.

There is a dedicated file previewer, published as a static site, for when the GitHub file viewer is not doing a good job of displaying a very large M3U file. That is a practical need rather than a nicety, because a half-million line playlist is not something a browser or a diff view handles gracefully.

For playback in the browser there are two routes. A web radio player at a separate site plays a newly curated list of playlists containing the checked streams, and the stream files in the repository root can be played through their own page using the Webamp player, which is a browser implementation of the Winamp interface. Using the playlist buttons, or clicking on entries and pressing play, are the two ways in.

The genre and decade tables in the README link to per-genre pages under a mrmp-extra path, so the same collection is browsable by category as well as playable in bulk. The genres run from americana and acid_jazz through ambient, anime, big_band, bluegrass, blues, breakbeat, chillout, classical, club, college, comedy, country, dance, disco, discofox, downtempo, drum_and_bass, easy_listening, ebm, electronic, eurodance, film, folk, funk, goa, gospel, gothic, hardcore, hardrock, hip_hop, house, indie, industrial, instrumental, jazz, jpop and jungle. The decades are 60s, 70s, 80s and 90s.

The generate_index.js script at the root of the repository is the one piece of code in the project, and its name says what it does. Generating an index is what turns a flat directory of playlists into something browsable, and the fact that it is a single script rather than a toolchain is consistent with the rest of the project.

There are also sections on adding metadata to entries, converting between playlist formats, downloading from a station, and downloading the repository itself, plus sections on sources, related projects and the people behind it. The topics list includes kodi-ready, which tells you the target audience includes people who want to point a media centre at these files rather than only to listen in a browser.

The genre and decade tables in the README are the fastest way to understand how the collection is organised, because they are the public face of it. Every entry links to a per-genre page under a mrmp-extra path, so the same collection is browsable by category as well as playable in bulk. The genres run from americana and acid_jazz through ambient, anime, big_band, bluegrass, blues, breakbeat, chillout, classical, club, college, comedy, country, dance, disco, discofox, downtempo, drum_and_bass, easy_listening, ebm, electronic, eurodance, film, folk, funk, goa, gospel, gothic, hardcore, hardrock, hip_hop, house, indie, industrial, instrumental, jazz, jpop and jungle. The decades are 60s, 70s, 80s and 90s.

The generate_index.js script at the root of the repository is the one piece of code in the project, and its name says what it does. Generating an index is what turns a flat directory of playlists into something browsable, and the fact that it is a single script rather than a toolchain is consistent with the rest of the project.

There are also sections on adding metadata to entries, converting between playlist formats, downloading from a station, and downloading the repository itself, plus sections on sources, related projects and the people behind it. The topics list includes kodi-ready, which tells you the target audience includes people who want to point a media centre at these files rather than only to listen in a browser.

The limits of a scraped directory, and the alternatives

The honest limitation is that the project does not control any of the servers in the list. Every entry is a third-party stream hosted by a station that can change, close, or start requiring authentication at any time, and the checked set only tells you what was true at the last check.

There is also a licensing question that the documentation does not address. The list of URLs is not itself a copyright work, but a large collection of station metadata assembled by scraping, and what a station considers its metadata varies. The repository is MIT licensed, and it is worth reading the licence and the sources section before redistributing the data inside something commercial.

The alternatives come in three kinds. The first is a directory of the same shape maintained by someone else, and the practical difference between them is entirely in how recently the entries were checked, which is why the checked and full distinction matters more than the size of the collection.

The second is to use a directory service rather than a file, such as a radio directory site with an API, and to fetch from it at the time you need a list. The trade is that you get fewer stations and you get them fresh, whereas a static file gives you breadth and staleness.

The third is a maintained application rather than a dataset, where the application checks the streams and keeps its own cache. That is the approach that suits an installation you do not control, because the checking happens continuously rather than at commit time.

For the specific case of a Kodi box or a home listening setup, the practical pattern is to take a checked genre file, copy it to the device, and accept that a percentage of entries will be dead within a month. The topics include updated, which suggests the collection is refreshed, and a repository with a last push on 2026-10-20 is being worked on. The absence of GitHub releases means there is no version to pin, so the sensible practice is to take a copy of the file you like rather than pointing at the raw URL permanently.

Editorial conclusion

Adopt this collection if you need a broad set of internet radio streams in M3U format, and you are willing to deal with the fact that a stream that worked yesterday may not work today. Do not adopt it as a reliable playlist for a broadcast or a public installation, because the entries point at third-party servers the project does not control. Verify first by taking one genre file, playing a sample of entries with the dedicated file previewer, and checking how many of the streams you actually listen to are still alive before you build anything on top of the list.

Frequently asked questions

Official sources

1. Issues
2. junguler/m3u-radio-music-playlists on GitHub
3. Project website
4. README