Chinese-IPTV is two files, and the IPv4 streams in them have been failing

The repository is a data file, not a program

The top level of this repository contains four entries: `.github/`, `README.md`, `TV-IPV4.m3u` and `guide.xml`. There is no source code, no build system, no package manifest and no client.

That single fact frames everything else. There is nothing to install, nothing to compile, no API to call and no version compatibility to worry about. You point a player at a URL and it either works or it does not.

What you are consuming is a channel list in M3U format, described as a Chinese CCTV list, and an EPG guide in XMLTV format. The README links to the kodi_iptv_epg project by SoPudge in connection with the guide.xml EPG file.

This shape has an obvious advantage and an obvious cost. The advantage is that any client that speaks M3U and XMLTV can use it, which is a wide field including Kodi's PVR IPTV Simple Client and many standalone players. The cost is that there is no negotiation, no authentication, no fallback and no error reporting, because there is no program in the loop to provide any of those. Failure looks like a missing channel or a stream that never starts.

Two hosts, and the difference is aimed at mainland users

Every file is published twice, and the choice is not cosmetic.

The GitHub copies sit on the raw content host:

https://raw.githubusercontent.com/BurningC4/Chinese-IPTV/master/TV-IPV4.m3u

https://raw.githubusercontent.com/BurningC4/Chinese-IPTV/master/guide.xml

The second set is on the author's own domain, described as Cloudflare R2 and labelled as optimized for mainland users:

https://iptv.burningc4.com/TV-IPV4.m3u

https://iptv.burningc4.com/guide.xml

The README labels the Cloudflare R2 copies as optimized for mainland users.

The README presents the R2 domain as the option optimized for mainland users and also publishes GitHub raw copies. If you self-host or mirror, note that both files are pulled from the `master` branch, so the branch name is part of the URL contract.

The guide is UTC+8 and you may need to shift it

The EPG detail that will bite you is the timezone. The README states that time in `guide.xml` is UTC+8, and that you can change the EPG time shift number according to your own timezone.

UTC+8 is correct for the broadcasters this list targets, which is the point: the guide describes the schedule as the channels themselves publish it. Your player is likely running on UTC, so a naive import puts every programme two hours out or eight hours out depending on where you are, and the symptom is a schedule that looks plausible but is silently wrong.

The fix is a shift setting in your client rather than an edit to the file, and it is a setting you will need to change if your travel or your daylight saving changes. The README says to change the EPG time shift number according to your time zone, but does not document a particular client setting.

The second operational detail is refresh frequency. `guide.xml` is refreshed per hour, while the channel list has no stated refresh cadence at all. In a player that periodically reloads your source, expect the guide to update within the hour and the channel list only when it is replaced in the repository. Anything added to the channel list can therefore take far longer than an hour to reach your player, which matters if you are waiting for a new channel to appear.

The IPv4 streams have been failing since 2025-09-03

The first line of the README is a warning, and it is the most important thing on the page. It reports that as of the most recent test, on 2025-09-03, the IPv4 addresses in the live streams were not working again, and instructs users to switch to IPv6.

The phrasing is worth parsing carefully. It is not that the project is finished; it is that this particular failure mode has recurred, so the addresses that worked before have to be replaced and the file name `TV-IPV4.m3u` should not be read as a guarantee that the addresses inside it are IPv4-only or currently valid. The file is named after the intent, and the maintainer is telling you the intent is unmet.

For a user this means one concrete thing: check that your network has working IPv6 before you configure anything. If it does not, or if your client is on a network that drops IPv6, this particular channel list is the wrong input, no matter how the rest of the setup is configured.

For anyone planning to depend on the file programmatically, the lesson is about ownership. A list of live stream addresses is maintained by one person, is not generated by a described process, and can break on a broadcaster's side without the repository changing. Any automation built on it needs its own failure detection.

No licence, no releases, donation funded

The repository metadata reports no licence for the project, and the README has no licence section. For a personal configuration that is a formality. For anything else, from mirroring the list in a product to shipping it inside a hosted service, the absence of a licence means you have no grant of permission from the repository and no clarity about redistribution rights.

Release history is thin in the same way. The two listed releases, both tagged around the same day, are 20200301 on 2020-03-01 and 20200301-2 on 2020-03-01, the second described as updating the M3U. Nothing has been packaged or published since. The repository is not archived and the last push was on 2026-10-16, so the files themselves are still being updated even though nothing is released.

That gap between active commits and no releases is a useful signal. It means the files on `master` are the current state and there is no tagged version to pin to. If you need reproducibility, download both files and keep them.

The README also ends with a request for donations, illustrated with a payment QR code, alongside links for support requests. It is a single maintainer operation, which is worth remembering when you weigh the reliability of the streams against the effort involved in assembling an equivalent list yourself.

When this is the wrong source

Three situations make this repository a poor choice.

First, if you need more than Chinese CCTV channels. The description names CCTV, and nothing in the README suggests regional, international or user-contributed channel coverage. A list scoped to one broadcaster family is exactly right for a viewer in its target region and useless as a general IPTV source.

Second, if your client cannot fetch remote files. The README is explicit that this route applies to apps supporting a remote path, and names Kodi's PVR IPTV Simple Client as the example. If your player needs a local file, you are downloading `TV-IPV4.m3u` manually and pointing at a path on disk, which reintroduces the staleness problem.

Third, if you need anything like a service guarantee. There is no uptime statement, no fallback list, no schema for the M3U fields and no documented relationship between this repository and the broadcaster infrastructure it points at. When the streams fail, as they did according to the 2025-09-03 note, the only fix that exists is a new file committed by the maintainer.

The alternative is not really a competing project. It is generating your own playlist from streams you are entitled to receive, which gives you control over the addresses and none of the maintenance burden, at the cost of the curation work that makes this list worth using in the first place.

Editorial conclusion

Treat this repository as a data source rather than software: if your IPTV client accepts a remote M3U URL and you have IPv6 connectivity, pointing it at the Cloudflare R2 domain is the whole setup, and the guide file is worth adding because its UTC+8 timestamps need a shift to match your own timezone. Do not build automated tooling on top of it expecting a stable contract, because the repository has no licence statement, its only two releases date from 2020-03-01, and the author already had to post a warning that the IPv4 addresses stopped working. Before wiring it into anything, open TV-IPV4.m3u yourself and confirm your network can reach those streams, then confirm your player tolerates the guide's UTC+8 offset, and keep a local copy of both files because the upstream host can disappear without notice.

Frequently asked questions

Official sources

1. BurningC4/Chinese-IPTV on GitHub
2. Issues
3. README
4. Releases