iptv-org/iptv: a generated m3u you cannot pin to a version

index.m3u is generated from streams/, so editing it is pointless

The playlist a user downloads is an output, not a source. The repository root holds a streams/ directory with the underlying entries, a scripts/ directory where every operation is a separate command file, and a m3u-linter.json used by an external linter. The package manifest names the pipeline step by step, with format, generate, update, validate, lint, test, edit and export all under the `playlist:` prefix, plus a readme:update command that rewrites prose.

"playlist:generate": "tsx scripts/commands/playlist/generate.ts",
"playlist:lint": "npx m3u-linter -c m3u-linter.json",
"playlist:update": "tsx scripts/commands/playlist/update.ts"

Consequence: the file you open in a player is replaced whenever the update workflow runs, so a copy you kept for reference silently drifts, and a pull request that edits index.m3u by hand is not the entry point the project expects. Read streams/ and the generate script if you want to know why a channel is in the list or missing from it.

postinstall runs api:load, so installing needs the network

The manifest ends with a hook that does real work: `postinstall` runs `npm run api:load`, and that command runs scripts/commands/api/load.ts through tsx. The dependency list carries an @iptv-org/sdk package alongside the Octokit clients and the @freearhey helpers, which is how the data gets in.

That single line changes what a fork is. There is no vendored snapshot of the channel data in this repository, so the install step goes out to the network before you can run anything, and a clone made on a plane or behind a proxy fails at install rather than at use. Consequence: an offline or air-gapped deployment cannot be built from a git clone, and anyone planning a mirror has to arrange for that data to be fetched somewhere with connectivity and then carried over.

One URL for everything, and PLAYLISTS.md for everything else

The usage instruction is one sentence: paste the link to one of the playlists into any video player that supports live streaming and press Open. The main playlist containing all channels available in the repository is published at a single address:

https://iptv-org.github.io/iptv/index.m3u

Links to other playlists live in the PLAYLISTS.md file, and the player list itself is maintained in a separate awesome-iptv repository. So there is one default file that mixes every country and every language, and anything narrower means opening a second file and reading it. Consequence: a player that chokes on a very large playlist has no built-in smaller option to fall back on, and because the address is a page on the project's own site rather than a versioned release, every player subscribed to it silently receives a different list the next time the update workflow runs.

The channel data is in another repository, and so is the error report

This repository is the thin layer. All channel data is taken from the iptv-org/database repository, and the instruction for anything wrong is to open a new issue there, not here. Program guides come from utilities in iptv-org/epg, the API documentation lives in iptv-org/api, and other links are collected in iptv-org/awesome-iptv. Questions and ideas go to a Discussions board owned by the organization rather than by the repository.

Five or six repositories, one purpose each, and the one people land on is the one with the least content in it. Consequence for anyone building on top of this: correcting a channel name, a country or a logo is a change in a different repository, and it only reaches your player after that change is merged and the playlist is rebuilt. Budget for that delay instead of expecting a pull request here to change what you see.

Removing a link does not remove the stream behind it

The Legal section is unusually direct, and it is the part every reader should read. No video files are stored in this repository. It contains user-submitted links to publicly available stream URLs which, to the best of the project's knowledge, have been intentionally made public by the copyright holders. A link that infringes can be reported by opening an issue that uses the copyright claim template.

Then the limits are stated. The maintainers have no control over the destination of a link, and removing the link from the playlist will not remove its contents from the web. Linking is described as not directly infringing copyright, because no copy is made on the site providing the link, and therefore not a valid reason to send a DMCA notice to GitHub. To remove content, the instruction is to contact the host actually serving it, not GitHub and not the maintainers. Consequence: if you publish a service built on this list, you inherit URLs nobody here can inspect or withdraw, and the takedown path points at a third party you have to identify yourself.

gh act runs the issue and label validators before you push

Five scripts in the manifest do not touch the playlist at all. They invoke the GitHub Actions runner locally, one per workflow file: check.yml, format.yml, update.yml, validate_issue.yml and validate_label.yml, each named act:check, act:format, act:update, act:validate_issue and act:validate_label.

Two consequences follow from that naming. The first is that a contributor can rehearse the same automation the repository runs on pull requests and scheduled updates, instead of guessing what CI will do. The second is that two of those five workflows police input rather than code: issues and labels are validated automatically, so a malformed issue template or a label the project does not recognise is rejected by machinery before a human reads it. The lint script covers scripts/ and tests/ only, and the test script runs vitest with --no-file-parallelism, so ordering is deliberate.

Unlicense in the repository, MIT in the manifest, no releases at all

Three facts about provenance belong together. The repository has no GitHub releases, so there is no tag and no version of the playlist to point a player at. The last push to the master branch was on 2026-09-29. And the licensing is stated in two places with different words: the LICENSE file at the root is the Unlicense, while the package manifest, which is marked private and is not published, declares MIT.

Because the manifest is private, that MIT field governs nothing you install; the Unlicense is the document that covers the repository contents, and the stream URLs inside it remain the property of whoever hosts them. Consequence: link rot, dead streams and channel changes are all things you will discover at playback time, not in a diff, because there is no release to compare against. Keep the date of the fetch with any list you rely on, and re-check it rather than trusting a subscription you set up months ago.

Editorial conclusion

Use this repository when you want a broad, automatically refreshed list of publicly available channels and can accept that the URL is a moving target. Do not build anything that needs a fixed channel set, guaranteed uptime, or takedown responsibility, because none of that is here. Before you subscribe a player to it, record the date you fetched index.m3u, read the copyright claim procedure in the Legal section, and check the generated playlist in streams/ rather than trusting the published file to be stable.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository