XMLTV is an XML-based format for electronic programme guide data. It defines channels and programmes separately, then links programmes to channels through a shared channel identifier.
Core document structure
An XMLTV document typically has a
Channel identifiers
The channel id should be stable and unique within the guide. M3U playlists commonly copy that value into tvg-id so an IPTV application can join the video entry to programme data.
Programme times
XMLTV start and stop values use compact date/time strings that can include an explicit UTC offset. Incorrect offsets are a frequent cause of guides appearing one hour early or late around daylight-saving changes.
Titles, descriptions and categories
A programme can contain multilingual title, subtitle, description and category elements. Consumers may ignore unsupported fields, so do not rely on one optional element for essential identification.
Matching to M3U
Exact ID matching is the most dependable approach. Name matching can help recover from incomplete data but should be treated as a suggestion because punctuation and branding frequently differ between the playlist and guide.
Validating XMLTV
Check well-formed XML, unique channel IDs, programme references to existing channels and parseable timestamps. Large guides can be processed locally in a browser, but memory usage grows with file size.
Practical workflow for XMLTV Format Explained
A reliable way to work with XMLTV Format Explained is to create a small reproducible test before changing a production playlist or player configuration. Begin with the concepts covered above—Core document structure, Channel identifiers, Programme times—and confirm the expected result at each stage. Work from stable identifiers. Keep a small sample containing one M3U entry, its tvg-id, the matching XMLTV <channel> element and at least one <programme> record. This makes it possible to determine whether a failure is ID matching, missing programme data or timezone interpretation. This approach gives you a baseline that can be repeated after every change, which is far more useful than making several edits and then trying to infer which one affected the result.
Once the basic case behaves as expected, expand the test to the remaining areas: Titles, descriptions and categories, Matching to M3U, Validating XMLTV. Guide data should be tested independently of video playback. A channel can play with no EPG, and a perfect EPG match can exist for a stream that is offline. Exact identifiers are preferable to fuzzy display-name matching, while timestamps should retain explicit timezone information. Keep notes of the original input and the output produced by any editor, parser or converter. For larger playlists, entry counts, duplicate counts and metadata-completeness figures provide quick regression checks. If a result changes unexpectedly, return to the smallest known-good sample and reintroduce complexity one step at a time.
XMLTV Format Explained technical checklist
Before considering the job complete, review the following points against the actual use case rather than assuming that successful import in one application proves universal compatibility.
- Core document structure: XMLTV is an XML-based format for electronic programme guide data.
- Channel identifiers: An XMLTV document typically has a root element, one or more elements and many elements.
- Programme times: The channel id should be stable and unique within the guide.
- Titles, descriptions and categories: XMLTV start and stop values use compact date/time strings that can include an explicit UTC offset.
- Matching to M3U: A programme can contain multilingual title, subtitle, description and category elements.
- Validating XMLTV: Exact ID matching is the most dependable approach.
Common questions about XMLTV Format Explained
Does understanding XMLTV Format Explained prove that a stream will work?
No. XMLTV is an XML-based format for electronic programme guide data. It defines channels and programmes separately, then links programmes to channels through a shared channel identifier. Playlist or manifest structure is only one layer. Availability, authorisation, network delivery and decoder support must be tested separately where they apply.
What should I preserve before making changes?
Keep the original text or file, note the player/device used for testing and record any stable identifiers such as tvg-id. For HLS work, keep the original manifest and any relevant child-manifest relationship. A known-good baseline makes rollback and comparison straightforward.
Which M3U.co.uk tool is the best starting point?
For general M3U structure, start with the M3U Checker. Use the Playlist Analyzer for counts and metadata, the M3U Editor for structured changes, and the HLS Inspector when the input contains HLS #EXT-X- directives.
Inspect or edit your playlist
Use M3U.co.uk’s browser tools. Playlist content is processed locally unless a tool explicitly states otherwise.