EPG¶

Abstract¶

EPG means electronic programme guide and it allows a viewer to navigate through the programs for available channels.

In Managed OTT an administrator can either create the EPG using the customer portal or it can be imported or sent in from an external system.

Currently this page describes only the process of loading EPG data into the system not the general structure of an EPG or how to use it from a client/app

Interfaces¶

Customer Portal¶

An administrator can create and maintain the EPG directly in the customer portal. In the customer portal it is also possible to view and verify an EPG sent in or retrieved from an external system. In this case the EPG will normally be in a read-only mode since our system is not the master.

System integrations¶

Managed OTT can be integrated with external systems owning the EPG information. Currently we support the following integration types.

API. A customer can send in EPG data by simply posting data to our management API EPG endpoint. Supported formats: XML TV, TVANYTIME and the Redbee JSON format.
PULL API. The customer or a supplier can expose an http(s) endpoint where it is possible for us to fetch the EPG information when needed. Supported formats: XML TV.
Content Discovery. RedBee division Content Discovery can be responsible for maintaining the EPGs. If this is the case we have a direct integration towards their API. A separate contract with Content Discovery is needed for this.
Generated. A special case. There are no EPGs available for the channel, but for reasons its desired anyway. In this case we can generate default programs with a specified duration, for instance 1 hour.

All configurations can be seen in the customer portal but the initial setup must be done by Managed OTT support.

PULL API requirements¶

The PULL API path means that the customer or a supplier is responsible for maintaining an endpoint that is always available returning the EPG. As stated above we currently expect it to return XML TV. The endpoint is reachable using a stable URL that we can have configured in our platform. At the moment we cannot add or change the URL so either the endpoint always return a pre-defined interval, such as the coming 7 days, or it should have a query param setting number of days. Examples:

https://example.com/getEPG - OK. Always return relevant period
https://example.com/getEPG?daysForward=7&daysBackward=3 - OK. Return data based on parameters that do not require updates.
https://example.com/getEPG?startDay=2021-06-03&endDay=2021-06-08 - Not OK since it require us to update the query parameters every time.

Formats¶

When loading EPG data into our system it is possible to use different supported formats. Two XML standards and one RedBee specific JSON format are supported.

XML¶

Two different XML formats are supported. In both cases it is very important to mention two things

All mappings we do from our supported formats into our internal storage format is described in the following mapping specification

We support the exact version mentioned, for instance for TVAnytime there are a lot of versions available.
We implement support on field level based on requirements. Both formats are very generic and it is possible to put in a lot of different information. We use what is stated in the mapping documentation nothing else. Support for new mappings can be added but that must be negotiated with our product management.

TVANYTIME¶

First supported format is TV Anytime. Note that we support this exact version of tva_metadata_3-1_v181. TVAnytime is a very generic format and we only support it as described in the mapping documentation.

XML TV¶

Second supported format is XML TV. Also for this format we support a specific version xmltv and in the same way this is also a very generic format and we only support it as described in the mapping documentation.

A simple example using the elements that are currently supported can be found here.

JSON¶

RedBee 1.0¶

RedBee 1.0 is the first version of a custom developed EPG format available since March 2024. Note that this format is currently only supported when being sent in by the customer using the API interface. To send in JSON the same endpoints as for XML is used but the content type should be application/json instead of application/xml.

All available elements are explained in format.json. An example is available in example.json.