Skip to content

Time zone compensation (timezone shift)

This page covers a common local ISP edge/headend scenario where TV channels are ingested from an upstream provider, but subscribers are in a different time zone.

Example customer goals:

  • ingest channels once from the provider;
  • deliver locally (1-to-many) to reduce WAN bandwidth;
  • for selected “premium” channels, provide a fixed delay, e.g. (6h), and offer catchup.

Catena SE solves this via DVR/nPVR: record the channel first, then read the archive with an offset.

Time basics

  • Treat all times in APIs/URLs as UTC epoch seconds.
  • A (6h) offset is 21600 seconds.

Requirements

  • The channel must be recorded to the archive.
  • The archive depth must be greater than the desired offset. For (6h), keep extra headroom (e.g. 8–24 hours) to tolerate gaps and upstream incidents.

Method 1 (recommended for popular channels): a delayed channel

This is the best 1-to-many approach: the archive is read once, regardless of the number of viewers.

Concept:

  • you have a source channel channel that is recorded to the archive;
  • you create a second channel that reads from the archive with a constant delay.

For a 6-hour delay, the offset is 21600 seconds.

This “delayed channel” is then delivered like a normal live channel and can be exposed via /lb/.

If you implement this as a separate “delayed channel” in Catena SE, then (similar to Flussonic Media Server) its source can be configured as reading the archive of the original channel with a fixed offset, for example:

timeshift://channel/21600

Example setup in the UI (source channel recorded, 1-hour offset — 3600 seconds):

  1. In the Channels section you already have a channel with archive (e.g. recorded). Create a new channel for delayed playback.

Channel list

  1. The new channel page opens. Go to the Inputs tab.

Created channel page

  1. Add source timeshift://recorded/3600 (or timeshift://recorded/21600 for a 6-hour offset) and save.

Timeshift source configured

  1. On the Basic tab, the built-in player shows the delayed stream.

Delayed channel player

How it relates to catchup (EPG)

Time zone compensation and catchup solve different tasks and are typically used together:

  • time zone compensation: “watch live as if it were in my local time” (fixed offset such as 6 hours);
  • catchup: “watch a specific program from EPG” (archive using from/duration).

Middleware recommendation:

  • if you present the delayed channel as a separate live channel, your UI/EPG should usually be shifted accordingly (handled by middleware);
  • for catchup URLs, follow the same rules as in nPVR and playback (UTC epoch, archive-<from>-<duration>).

Practical mapping for a fixed offset:

  • if you show EPG for the “delayed channel” shifted by (+21600), then when generating a catchup link to the original channel archive use from = from_displayed - 21600;
  • example: a user selected a program with from_displayed in the shifted EPG. For HLS, build:
https://<hostname>/lb/-/<name>/archive-<from_displayed-21600>-<duration>.m3u8

Practical notes for edge/headend

  • Delayed channels read archive from the disk only once per stream, then all users are served from memory.
  • Size storage based on bitrate: (channels \times bitrate \times hours).