Is tvg-id matching case-sensitive?

The specs do not mandate either behavior, so it depends on the player. Because this is unreliable across apps, treat it as case-sensitive when authoring playlists and always mirror the exact casing used in the XMLTV channel id.

Can tvg-name alone match a channel to its guide without tvg-id?

Some players support this as a fallback, but it is a convention rather than a standard, and it depends on the display name text being identical in both files. It is a weaker mechanism than tvg-id because display names vary more (HD suffixes, punctuation) between playlist authors and guide providers.

Why did a channel that used to have guide data suddenly show none?

If nothing in the playlist changed, check whether the XMLTV source was swapped, updated, or is now failing to fetch — the tvg-id in the playlist has not changed, but the guide file may no longer define a channel with that id, or may have merged with a second source that overrode it.

Does a numeric tvg-id like "111" work the same as a text one like "BBCOne.uk"?

Yes — the match is a plain string comparison regardless of whether the id looks numeric or textual. What matters is that the exact same string appears as the channel id in the XMLTV file, not the format of the string itself.

tvg-id EPG matching: why channels show no guide data

tvg-id EPG matching works by string equality: the tvg-id attribute on an M3U channel must exactly match the id attribute of a <channel> element in the XMLTV file for the app to attach that channel's programme data. When a channel shows "no programme information available," the cause is almost always that these two strings do not match exactly, not that the guide data is missing.

This failure is silent by design — most players do not warn you that a tvg-id had no matching channel in the EPG, they just render an empty guide row. Diagnosing it means comparing the exact tvg-id string against the exact XMLTV channel id, character for character, rather than assuming the guide provider does not cover that channel.

This guide walks through where the two strings come from, the specific formatting differences that cause a mismatch, and how to tell a matching problem apart from a genuinely missing guide source.

Where each side of the match comes from

On the playlist side, tvg-id is an attribute on the #EXTINF line: #EXTINF:-1 tvg-id="BBCOne.uk" tvg-name="BBC One",BBC One. On the guide side, an XMLTV file defines channels with <channel id="BBCOne.uk"><display-name>BBC One</display-name></channel>, and programme entries reference that same id: <programme channel="BBCOne.uk" start="..." stop="...">. The player's only job is to find a <channel> element whose id attribute equals the tvg-id string, then show that channel's <programme> entries for the current time window.

Because this is a plain string comparison, capitalization, whitespace, and even invisible characters all count. "BBCOne.uk" and "bbcone.uk" are different strings to a strict matcher, even though most humans would read them as the same channel.

The formatting mismatches that break matching most often

Trailing or leading whitespace inside the quotes is the single most common cause — a playlist generated by a spreadsheet export or hand-edited in some text editors can pick up a trailing space on tvg-id that is invisible when reading the file but fails a strict equality check against the XMLTV id.

Domain-suffix conventions differ between providers: one XMLTV source might use "BBCOne.uk" as the id while another uses just "BBCOne" or a numeric id like "111". If the playlist tvg-id was written against a different guide provider's convention than the one currently configured, every channel can fail to match even though both files are individually well-formed.

Case sensitivity is not defined by the XMLTV or M3U specs to be case-insensitive, so relying on players to normalize case is a gamble — some do, many do not. The safest approach is byte-for-byte identical strings on both sides.

When tvg-name is used as a fallback match key

Some players fall back to matching on tvg-name against a <display-name> element when tvg-id is absent or unmatched, but this fallback is inconsistent across apps and is not part of any formal spec — it is convention borrowed from XBMC/Kodi-era tooling. Relying on tvg-name matching means the match now depends on the display name being written identically in both files, including punctuation like "BBC One HD" versus "BBC One (HD)", which is a much weaker guarantee than a stable tvg-id.

How to tell a mismatch from a genuinely absent guide

If the XMLTV source has no <channel> element at all for a given service, no amount of tvg-id correction will produce guide data — the fix is a different or additional XMLTV source, not a playlist edit. The distinguishing check is to search the raw XMLTV file for the display name as free text; if it appears nowhere, the source simply does not carry that channel, but if it appears under a different id, that confirms a fixable string mismatch.

A channel that matches correctly but shows only partial guide data (say, six hours of programmes and then nothing) is a different problem — that is an XMLTV coverage gap, not a tvg-id mismatch, and is diagnosed by checking the programme start/stop timestamps rather than the channel ids.

Multiple EPG sources and merge conflicts

Some apps let you load more than one XMLTV source and merge them. If two sources both define a <channel id="BBCOne.uk"> element, the app has to pick one, and the behavior for which one wins (first loaded, last loaded, or by source priority order in settings) is app-specific and not standardized. A channel that had guide data yesterday and does not today, with no playlist change, is often explained by a merge-priority change or one of the two sources going stale.

Step by step

Copy the exact tvg-id string from the #EXTINF line, including case.
Search the XMLTV file for a <channel> element whose id attribute is that exact string.
If no exact match exists, search the XMLTV file for the channel's display name as free text to see if it exists under a different id.
Check for leading or trailing whitespace inside the tvg-id quotes that would not be visible in a normal text view.
If tvg-id is absent, check whether the player is falling back to tvg-name and whether that string matches a <display-name> exactly.
If the channel exists under a different id, update the playlist tvg-id to match the XMLTV id rather than trying to change the guide source.

Run it yourself

Free, no sign-up, and every finding links to an explainer.

EPG matcher →EPG checker →M3U checker →

Frequently asked questions

Is tvg-id matching case-sensitive?: The specs do not mandate either behavior, so it depends on the player. Because this is unreliable across apps, treat it as case-sensitive when authoring playlists and always mirror the exact casing used in the XMLTV channel id.
Can tvg-name alone match a channel to its guide without tvg-id?: Some players support this as a fallback, but it is a convention rather than a standard, and it depends on the display name text being identical in both files. It is a weaker mechanism than tvg-id because display names vary more (HD suffixes, punctuation) between playlist authors and guide providers.
Why did a channel that used to have guide data suddenly show none?: If nothing in the playlist changed, check whether the XMLTV source was swapped, updated, or is now failing to fetch — the tvg-id in the playlist has not changed, but the guide file may no longer define a channel with that id, or may have merged with a second source that overrode it.
Does a numeric tvg-id like "111" work the same as a text one like "BBCOne.uk"?: Yes — the match is a plain string comparison regardless of whether the id looks numeric or textual. What matters is that the exact same string appears as the channel id in the XMLTV file, not the format of the string itself.