Program recording (nPVR)¶
Catena SE can record a TV channel to disk for later playback, both for programs that have already finished and for programs that are still being recorded right now.
In the templates shipped with Catena SE, archive recording is enabled by default. It uses the resources of the servers you provided when adding a server.
Recording includes all video qualities and also screenshots.
Via API you can request the list of programs for a channel, and if the middleware answers the required request using the config-external protocol, Catena SE returns programs enriched with the recording status field.
Archive recording architecture¶
The archive is recorded after the transcoder¶
In Catena SE the archive is recorded after the transcoder: the disk stores video already prepared for delivery (all qualities/tracks configured in the template).
This matters for two reasons:
- the archive is immediately playable on client devices (Smart TV / STB / mobile) without extra processing;
- storage sizing and load are based on the actual output profile set (MBR), not on the raw input streams.
Storage: local disks only + replication between servers¶
Catena SE records the archive strictly to local disks on the servers.
We do not use NFS, disk shelves/SAN, or other shared network storage: they add complexity and often reduce predictability of latency and reliability.
Recommended storage model:
- many cheap separate disks (usually HDD) for large archive capacity;
- archive replication between cluster servers to survive a disk/server failure;
- disk configuration and mount points are defined when adding the server (see Add a new server).
SSD cache for high-scale archive playback¶
To serve a large number of concurrent viewers, Catena SE follows the approach “lots of archive on HDD, the hottest parts on SSD”.
Typical setup:
- the main archive volume is stored on local HDDs;
- the most frequently requested fragments (for example, “last hours” or “prime time”) land in SSD cache;
- this allows a significant increase in parallel playback without the cost of storing the whole archive on SSD.
How this is typically used in IPTV (catchup TV)¶
The most common user tasks built on top of the archive:
- pause live TV and resume from the same spot
- start the current program from the beginning (startover)
- watch yesterday’s program using EPG
- save “progress” and continue later
Technically these scenarios are easiest in RTSP, but IPTV/OTT primarily uses segmented HTTP protocols (HLS, DASH, and sometimes MSS), so pause/seek/startover rely on special URLs and playlists.
Time and program identifiers¶
In this documentation, program time is considered only as a Unix timestamp in UTC seconds (Epoch).
Do not use local time in archive playback logic: it almost always leads to errors with time zones, DST, and multi-region users.
It is recommended to store the current playback position (UTC timestamp or offset) in the middleware database so you can offer “resume” or “start from the beginning” on the next open.
Playing an archived program using EPG (VOD playlist)¶
If your middleware stores EPG schedule, each program has:
from— start time in UTC (epoch)to— end time in UTC (epoch)
Duration is computed as (duration = to - from).
To play a program from the archive, build a URL following Play a TV channel.
Example for HLS:
https://<hostname>/lb/-/<channel>/archive-<from>-<duration>.m3u8
Example for DASH:
https://<hostname>/lb/-/<channel>/Manifest-<from>-<duration>.mpd
With this access method, players typically support:
- seeking within the program
- pause
- fast playback
When playback finishes, it is recommended to automatically switch to the next program in EPG to keep viewing continuous.
Watching the current program: event playlists and “pause live”¶
For startover and pausing the current program, you can use the same URL as for archive playback, but with the end of the window in the “present” or in the future.
The trick is that if the specified end time is in the future, the playlist is served not as VOD but as EVENT, which allows the player to re-fetch it and move forward.
If your client platform supports it, use the same URL as for the archive and add event=true:
https://<hostname>/lb/-/<channel>/archive-<from>-<duration>.m3u8?event=true
Where from and duration correspond to the current EPG program.
Important note about the “live” button¶
In most cases, the “live” button must be implemented explicitly.
While the user stays paused, things can change:
- an EVENT playlist can eventually turn into VOD (the window “closes”);
- the player may stop refreshing the playlist;
- when the program changes, the “current program” playlist ends.
In this case you should:
- determine the current program via EPG,
- rebuild the URL for the relevant period,
- or jump to the next EPG item.
Platform limitations¶
Event playlists and seeking “within the current program” can be limited on certain platforms (for example, native Safari).
If such platforms are critical for you, plan for a dedicated timeline/seek implementation in the app (usually in JavaScript or native SDK) on top of the same EPG data and URLs.