Television EPG Data: A Case Study in Legacy Metadata

Summary: Electronic Programme Guide (EPG) data appears, at first glance, to be a solved problem. Television schedules have existed for decades, digital broadcasting has been commonplace since the 1990s, and modern IPTV platforms can deliver high-definition content to millions of users across multiple devices. Yet developers attempting to consume EPG data quickly discover a surprising reality: television metadata is often incomplete, inconsistent, poorly structured, and difficult to classify.

This article explores why EPG data remains problematic, how the industry arrived at its current state, and why identifying something as simple as a movie can still require a combination of guesswork and heuristics.

Context

For many developers, the journey begins with a seemingly straightforward requirement:

• Download an EPG feed
• Import programme listings
• Identify films
• Present the data to users

The assumption is usually that every programme entry contains rich metadata describing its content.

For example:

<source lang="xml"> <programme>

   <title>Jaws</title>
   <type>Movie</type>
   <genre>Thriller</genre>
   <year>1975</year>

</programme> </source>

In reality, many freely available EPG feeds look more like this:

<source lang="xml"> <programme>

   <title>Jaws</title>
   <desc>(1975) Roy Scheider stars as a police chief...</desc>

</programme> </source>

The information exists, but it is embedded within human-readable text rather than exposed as structured data.

This creates challenges for:

• IPTV platforms
• PVR systems
• Media servers
• Search engines
• Recommendation engines
• Analytics systems

What is an EPG?

An Electronic Programme Guide is a dataset describing television and radio schedules.

At its simplest, an EPG contains:

• Programme title
• Start time
• End time
• Channel

Additional information may include:

• Description
• Category
• Genre
• Cast
• Rating
• Episode details
• Images
• Series and season numbers

The XMLTV format has become the de facto standard interchange format for EPG data within the open-source community.

A typical XMLTV entry contains:

<source lang="xml"> <programme start="20260712190000 +0100"

   stop="20260712210000 +0100"
   channel="film4">

   <title>The Great Escape</title>
   <desc>(1963) Allied prisoners attempt a daring escape...</desc>

</programme> </source>

The specification supports extensive metadata; however, the presence of that metadata depends entirely on the source providing the feed.

The Origins of the Problem

To understand the shortcomings of modern EPG data, it is necessary to understand its origins.

Electronic programme information was not originally designed to power search engines, recommendation systems, machine learning platforms, or content discovery applications.

It was designed to power:

• Teletext
• Set-top boxes
• Electronic programme guides
• Basic recording systems

The primary requirements were simple:

1. What is currently on?
2. What is on next?
3. When does it start?
4. When does it end?

Everything else was considered optional.

As a result, many metadata systems evolved around presentation rather than structured classification.

The Legacy Metadata Trap

Many broadcasters maintain rich internal databases describing their content.

Internally they may know:

• Programme type
• Production company
• Genre
• Sub-genre
• Contributors
• Release year
• Awards
• Content warnings

However, this information often passes through multiple systems before reaching end users.

The pipeline typically resembles:

Broadcaster
    ↓
Metadata Supplier
    ↓
EPG Aggregator
    ↓
Platform Provider
    ↓
Consumer Application

At each stage information may be:

• Simplified
• Reformatted
• Lost
• Reinterpreted

The result is that downstream consumers frequently receive a reduced version of the original metadata.

The Movie Identification Problem

A practical example illustrates the issue.

Suppose we wish to identify all movies in an EPG feed.

Ideally we would simply query:

<source lang="php"> if($programme->type == "Movie") {

   // Film detected

} </source>

Unfortunately this field is often unavailable.

Developers therefore resort to heuristics.

Duration-Based Detection

Movies are generally longer than television programmes.

A simplistic approach might be:

<source lang="php"> if($duration > 90) {

   $isMovie = true;

} </source>

This works surprisingly often.

However, it also captures:

• Sporting events
• Award ceremonies
• Concerts
• Extended documentaries

Description Analysis

Many listings include a release year.

For example:

(2019) Elton John's rise to fame...

or

(1989) Tom Hanks stars...

This allows detection using pattern matching:

<source lang="php"> if(preg_match('/^\([0-9]{4}\)/', $description)) {

   $isMovie = true;

} </source>

While effective, it remains a workaround rather than a reliable solution.

Channel-Based Detection

Movie-focused channels provide another clue.

Examples include:

• Film4
• GREAT! Movies
• Movies24
• Talking Pictures TV

A two-hour programme on a dedicated movie channel is highly likely to be a film.

Again, however, this is inference rather than structured classification.

Why IPTV Did Not Solve the Problem

Many people assume IPTV introduced a fresh start.

In reality, IPTV largely inherited the metadata ecosystem created by traditional broadcasting.

The primary innovation of IPTV was the transport mechanism rather than the programme information itself.

An IPTV platform often receives schedule data from third-party suppliers rather than generating metadata independently.

Consequently:

• Poor metadata enters the platform.
• Poor metadata leaves the platform.

The transport became modern.

The metadata often remained legacy.

This explains the curious situation where a service can stream:

• 4K UHD
• HDR
• Dolby Atmos
• Multi-device playback
• Cloud recording

while still struggling to reliably determine whether a programme is a movie.

Comparing Television and Music Metadata

The contrast with music services is striking.

Modern music platforms usually understand:

• Artist
• Album
• Genre
• Track duration
• Composer
• Release date
• Label

These attributes are well understood and consistently represented.

Television metadata remains considerably less standardised.

In many EPG feeds, the distinction between:

• Film
• Drama
• Documentary
• Special Event
• Miniseries

may exist only within free-text descriptions.

Why Free EPG Feeds Are Often Limited

Free EPG providers face a difficult challenge.

They must gather information from:

• Broadcast streams
• Public listings
• Multiple regional variants
• Different metadata formats

While maintaining a freely accessible service.

As a result, many free feeds prioritise:

• Accuracy of schedule times
• Broad channel coverage
• Automated generation

over deep metadata enrichment.

This is entirely understandable.

Maintaining schedule accuracy across hundreds of channels is already a significant undertaking.

Practical Strategies for Developers

When consuming EPG data, developers should assume metadata quality will vary.

A robust solution typically combines several approaches:

Layer 1: Explicit Metadata

Use category and genre information when available.

Layer 2: Description Parsing

Extract:

• Release years
• Keywords
• Content ratings

from programme descriptions.

Layer 3: Duration Analysis

Use runtime thresholds to identify likely long-form content.

Layer 4: Channel Classification

Maintain channel-specific rules where appropriate.

Layer 5: External Enrichment

Supplement EPG data using:

• Media databases
• Broadcaster APIs
• Content discovery platforms

This transforms schedule data into a richer catalogue.

Design and Architecture Considerations

When building systems around EPG data:

Expect Inconsistency

Never assume every field exists.

Preserve Original Data

Store raw source data for auditing and reprocessing.

Separate Classification Logic

Avoid embedding assumptions throughout application code.

Instead:

Raw EPG
    ↓
Normalisation
    ↓
Classification
    ↓
Presentation

This allows heuristics to evolve without re-importing data.

Measure Confidence

Rather than storing:

Movie = True

consider:

Movie Confidence = 92%

This better reflects the uncertainty inherent in many EPG sources.

The Great Irony

Perhaps the most interesting aspect of television metadata is that the content delivery systems have evolved dramatically while the descriptive data often has not.

Over the last few decades we have moved from:

• Analogue broadcasts
• Digital television
• Satellite platforms
• Cable systems
• IPTV
• Streaming

Yet developers still frequently identify films using little more than:

<source lang="php"> $runtime > 90 </source>

and

<source lang="php"> strpos($description, '(2024)') </source>

For an industry capable of delivering ultra-high-definition video globally, this can feel surprisingly primitive.

Conclusion

Electronic Programme Guide data is an excellent example of legacy metadata surviving within modern systems.

The challenge is not the transport of television content. Modern platforms solved that problem years ago.

The challenge is describing that content consistently.

For developers, system architects, and data engineers, EPG data serves as a valuable reminder that structured information is often more difficult to obtain than the content itself.

Sometimes the most challenging part of a television platform is not delivering the programme.

It is simply determining what the programme actually is.

Related Topics

• XMLTV
• Electronic Programme Guides
• IPTV Architecture
• DVB Standards
• Metadata Normalisation
• Data Classification
• Media Information Systems

References

• XMLTV Project
• DVB Service Information Specification
• Freeview Broadcast Metadata Standards
• BBC Programmes API
• IPTV Electronic Programme Guide Systems
• Digital Television Service Information Standards