# vbskycn/iptv: a Chinese IPTV playlist repository that refreshes every six hours

> The repository is not a player. It publishes M3U and TXT channel lists for IPv4 and IPv6 networks, scanned and rewritten by a scheduled workflow, with a GitHub proxy as the fallback when the project's own domain is blocked.

**vbskycn/iptv** — iptv最新可用直播源,支持iptv4/iptv6双栈访问。直播电视系统，这里有折腾好的，直接下载用吧。直播电视app电视手机全部兼容。

- Repository: https://github.com/vbskycn/iptv
- Website: https://izbds.com
- Stars: 8,697 · Forks: 1,277
- Language: HTML
- License: GPL-3.0
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/vbskycn-iptv

## What vbskycn/iptv actually ships: playlists, not a player

The repository is a distribution point for IPTV channel lists in Chinese. Its README describes it as a project that collects sources from public resources on the internet through a GitHub workflow, and it is explicit that it stores no streaming content itself. What you get are two families of files under the tv/ directory: iptv4.txt and iptv4.m3u for IPv4 networks, and iptv6.txt and iptv6.m3u for IPv6. The M3U variants are described as already carrying channel logos and EPG, though a later changelog entry states the project stopped providing EPG service on 2025-05-20, so the logos are the part you can rely on.

The audience is narrow and specific. Someone who already has a player, wants Chinese channels, and does not want to run a scanner themselves. The README says the lists work on Apple and Android 4.0+ TV boxes, phones, and computers, which is really a statement about the M3U format rather than about any code in the repository. There is no companion app here. If you want an app, the README points at a third-party one called 直播电视 at izbds.com/aztv/ and says the repository itself is for people who are willing to 折腾, that is, to tinker.

## How the six-hour scan works and where the files come from

Two things run on a timer, and they are different mechanisms. The first is the source scanner. The README says the IPv4 and IPv6 lists are produced by programs deployed on servers that scan and validate streams automatically, and the page carries update markers for each list. The visible marker in the README shows a single timestamp shared by both lists, which tells you the two scans are published together rather than independently.

The second is a GitHub Actions workflow named Sync with Upstream Repository. This one does not touch the streams at all. It exists so that a fork stays level with the upstream repository, checking every six hours, merging changes, and resolving conflicts in favour of the remote. The README is careful about one GitHub behaviour here: workflows containing a schedule trigger and a workflow_dispatch trigger are disabled by default in a fork, so a forked copy will silently stop syncing until you open the Actions tab and enable the workflow manually. That is the single most common way a fork of this project goes stale without anyone noticing.

The files are served two ways. The project domain live.zbds.top serves them directly, and raw.githubusercontent.com URLs serve the same files from the repository. The README notes that some broadband operators have poisoned the project domain, which is why the proxy form exists.

## IPTV setup: pointing a player at the list and checking it loaded

There is nothing to install. The repository publishes URLs, and your player consumes one of them. The four canonical endpoints named in the README are the IPv4 TXT and M3U lists and the IPv6 TXT and M3U lists on live.zbds.top.

If the project domain does not resolve or returns something unexpected, the README gives the proxy form, which fetches the same file through gh-proxy.com:

```bash
https://gh-proxy.com/raw.githubusercontent.com/vbskycn/iptv/refs/heads/master/tv/iptv4.txt
https://gh-proxy.com/raw.githubusercontent.com/vbskycn/iptv/refs/heads/master/tv/iptv4.m3u
```

Before handing either URL to a player, open it and confirm you are getting a playlist rather than an error page or an ISP interstitial. A working M3U response begins with the extended M3U header and then a series of channel entries. The README does not give a command for this check, and it does not name a specific player or document any per-player configuration, so the field name depends on the software you use. Once a URL returns a playlist, paste it into your player's remote playlist or subscription field.

## The IPv6 list is the part most likely to disappoint you

The README carries an unusually direct warning about the IPv6 side. It states that for reasons it calls outside its control, most IPv6 sources have closed, that the large operators now keep to themselves, and that users can no longer expect one list to cover everything. The repository says it will publish any operator that reopens, but the honest reading is that iptv6.txt and iptv6.m3u may be thin.

There is a second, structural limitation. The README's disclaimer is unambiguous that the project does not guarantee the availability, stability, or legality of any source, and that all responsibility falls on the user. A validated stream at scan time is not a stream that will be alive when you press play an hour later. The changelog supports this: an entry from 2024-09-09 says sources were failing so quickly that a new Debian server was added to update three times a day. The scan cadence is a mitigation, not a fix.

Finally, the project is the wrong tool if you need programme guide data. EPG service was withdrawn on 2025-05-20 according to the changelog, so any player relying on this list for schedule information will show channels without a guide.

## Forking versus using the published URLs, and what the licence covers

The repository is licensed GPL-3.0, and the default branch is master. The README asks that anyone reusing its content in another repository comply with the licence and credit the source. Note what the licence actually attaches to: the HTML site, the templates under _includes/ and _layouts/, the tools/ directory, and the workflow files. It does not attach to the streams, which the README says come from third parties and which the project does not host. Copying the repository is a licensing question; rebroadcasting the streams is a different question the licence does not answer, and the README's disclaimer pushes that onto the user.

Forking buys you one thing: a copy of the lists under your own account, refreshed by the sync workflow. It costs you the manual step of enabling Actions after the fork, and it gains you nothing about stream availability, since the scanner runs upstream. The pragmatic choice for most users is to consume the published URLs and not fork at all. Fork if you intend to modify the site or the tooling, not if you just want the channel list.

## How this differs from iptv-org and similar index projects

The obvious comparison is iptv-org/iptv, which also publishes M3U playlists and also relies on automated checks. The difference is scope and geography. iptv-org aims at a global index organised by country and language, with contributions accepted from the community and a much larger set of streams. vbskycn/iptv is a single-operator Chinese-language list, published on its own domain, with the README written for an audience that wants CCTV and provincial satellite channels without assembling anything.

That focus cuts both ways. A single maintainer with a fixed scanning pipeline can move quickly when Chinese sources change, and the update markers show that happening. It also means there is no contributor process, no per-channel metadata beyond what the scanner captures, and no fallback if the maintainer stops. The README even reserves the right to modify or terminate the project at any time. If you need a list with a governance model and a contribution path, this is not it. If you need a Chinese list that someone else is actively rescanning, it is.

## Maintenance cost, and the one workflow setting that breaks forks

Running the repository costs nothing. There is no build step for a consumer, no server to host, and no dependency to update. The maintenance burden sits entirely upstream, where the scanner and the sync workflow run. The last push to the repository was on 2026-09-21, the day before the README's own update marker, so the project is being touched on a short cycle.

For a fork, the cost is one manual action and one ongoing risk. The Sync with Upstream Repository workflow is disabled after forking because GitHub does not run scheduled workflows in forks by default. Enabling it requires opening the Actions tab, acknowledging the prompt, selecting the workflow, and clicking Enable workflow. If you skip that, your fork's tv/ files freeze at the moment you forked them, and nothing in the repository will tell you. The README also states the sync resolves conflicts in favour of the remote and protects the workflow files, which means local edits to the lists in a fork are likely to be overwritten on the next sync.

## Conclusion

Adopt vbskycn/iptv if you already run a player that accepts a remote M3U URL and you want a Chinese channel list that is rescanned on a schedule rather than a file frozen at upload time. Skip it if you need EPG data, a player with a UI, or channels outside the Chinese and international set the scanners happen to validate, and skip it if you cannot legally receive those streams in your jurisdiction. Before pointing a player at it, open the M3U URL in a browser to confirm your ISP has not poisoned the domain and decide whether the gh-proxy.com raw URL is the one you will use, then check whether the iptv6 list still carries any entries given the README's note that most IPv6 sources have closed.

## FAQ

### What is the best URL for IPTV in the vbskycn/iptv project?

The README names four endpoints on live.zbds.top: iptv4.txt, iptv4.m3u, iptv6.txt, and iptv6.m3u. Which one is best depends on whether your network is IPv4 or IPv6 and whether your player reads TXT or M3U, since the M3U files are the ones described as carrying channel logos. If the project domain is blocked, the README gives the equivalent gh-proxy.com raw URLs.

### What are the details of the IPTV sources in vbskycn/iptv?

The README states the sources are collected from public resources on the internet by a GitHub workflow and validated by scanning programs on servers, with the IPv4 and IPv6 lists published under a shared update timestamp. It also states the project stores no streaming content, that all sources come from third parties, and that availability, stability and legality are not guaranteed.

### Does vbskycn/iptv include an EPG programme guide?

No. The changelog records that EPG service stopped being provided on 2025-05-20, even though the M3U files are still described as carrying channel logos.

### Why did my fork of vbskycn/iptv stop updating?

GitHub disables workflows that use a schedule trigger or workflow_dispatch in a forked repository, so the Sync with Upstream Repository workflow does not run until you open the Actions tab, acknowledge the prompt, select the workflow and click Enable workflow. Until you do that, the tv/ files in your fork stay as they were when you forked.

### Do I need to install anything to use vbskycn/iptv?

No. The repository publishes playlist URLs that an existing IPTV player consumes through a remote playlist or subscription field. The README does not name a player or document per-player settings.

## Sources

- [Issues](https://github.com/vbskycn/iptv/issues)
- [License: GPL-3.0](https://github.com/vbskycn/iptv/blob/master/LICENSE)
- [Project website](https://izbds.com)
- [README](https://github.com/vbskycn/iptv/blob/master/README.md)
- [vbskycn/iptv on GitHub](https://github.com/vbskycn/iptv)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/vbskycn-iptv
