Skip to content

Working with DVR Archive in Middleware

This article aims to assist Middleware developers in implementing video archive functionality to fulfill various user scenarios, including but not limited to:

  • Pausing live broadcast to take a break
  • Watching the current program from the beginning because they like the movie and want to start over
  • Watching yesterday's program
  • Bookmarking a favorite program to watch again in a few months

The problem addressed in this article is that the only protocol technically capable of easily implementing those scenarios is RTSP. However, RTSP has long been abandoned in favor of segment-based HTTP protocols: HLS, DASH (and a bit of MSS). None of these mainstream protocols for IPTV OTT support archive and DVR functionality out-of-the-box, hence the need for technical ingenuity to solve these tasks.

In our Media Server, we offer several approaches to address these challenges. The terms we use here are proprietary, as there are no industry standards.

Short Name Pros Cons
epg-vod Support for Pause and Fast forward Require player code; Require support for fast-forwarding in event
pseudo-live Play archive from any point without client modification Cannot Pause or Fast Forward

How to Best Manage Access to the Archive?

The most effective way to facilitate access to the archive is by using epg-vod for playing archived content, and using event for playing live broadcasts.

Playing Archive by EPG

For this method to work, the Middleware must maintain a precise EPG schedule. References to timestamps and time will be made throughout this section. We only consider seconds in UTC (Epoch time). Under no circumstances should local time be used, as it introduces unnecessary confusion.

When watching a program, it is recommended to store the current viewing time in the middleware database, so that upon reopening the user can choose whether to resume or to start from the beginning.

For example, when a user selects the program that aired from 1717677139 UTC to 1717679255 UTC from the archive, the following URL must be generated for the player: http://FLUSSONC-IP/STREAM_NAME/archive-1717677139-2116.m3u8?event=true

This URL allows the player to handle:

  • Seek within the program
  • Pause
  • Fast forward playback

At the end of playback, it is recommended to switch to the next program in the EPG to ensure a continuous flow of content to the viewer.

Viewing the Current Broadcast with Event Playlists

Viewing the current broadcast is technically more challenging. We recommend using event playlists, but they do not allow rewinding in native Safari, making them unsuitable for TV. In such cases you would need to write your own timeline code in JavaScript. If Safari is not critical for the operation, you can confidently use the same URLs as in epg-vod:


The trick is that if the playlist's closing moment is in the future, it will be served not as VOD, but as EVENT, allowing the player to re-request it and continue playing.

After this playlist ends, you should also switch to the next one according to the EPG and continue viewing.

Using such a URL allows pausing the live stream and resuming from the same spot. It is important to note that you need to program the "live" button yourself, because during the pause the playlist might automatically switch from EVENT to VOD and close. In this case, you need to determine the next program in the EPG and jump to it.

Pseudo-live DVR Access

The simplest most straightforward way to play the archive is to direct the player to pseudo-live from the archive using http://FLUSSONIC-IP:PORT/STREAM_NAME/timeshift_abs-1429829884.m3u8. For this request, a new session is created, and the time of creation is recorded on the server. With each subsequent request, the start of this playlist is shifted, and several segments are continually served, simulating a live stream.

The player streams the video that appears to be a live broadcast but is actually sourced from from the archive.

If such playback is paused for an extended period, the session on the server will expire and be deleted. After resuming, playback will start from the beginning.

We do not recommend using this approach except in cases where it is necessary, very quick to implement, and where client experience is not a primary concern.