Skip to content

The archive

A headend needs an archive not for the viewer's sake but as proof: what exactly did we send out at 03:40, was there a signal on the input at the moment of the complaint, what advertisement ran in the disputed hour. The recording happens on the same machine that receives and delivers.

The archive is a storage of its own: the stream is appended into hourly files, separately per track, across several disks at once. Reading the archive does not interfere with writing it.

The machine's disks

The disks are set once in the machine's settings, the DVR section. The panel warns right there: these settings change where the archive is written on the machine.

  • Archive root — the mount point, the home of the catalog and the base for relative paths.
  • Disk 1, Disk 2, … — with the Add disk button. A disk's path is the name of a subdirectory inside the root, not an absolute path.
  • Catalog path — the service directory for archive metadata; an empty field means <root>/catalog. This is not where the archive is stored.
  • Check the mount before writing — worth enabling always: without it a disk that fell off turns into an ordinary empty directory, and the station will write the archive into the root filesystem until that one runs out.

Without a single disk the settings will not save: DVR needs at least one.

Next to them live the cache disks — archive parts that were read settle there, whether from another machine or from local archive disks; live recording never picks them, and space is freed by how long ago a fragment was read. A headend rarely needs them — mostly when it serves the archive of neighbouring machines.

Recording a stream

Open the stream, the DVR tab, turn on Record to DVR and set the limits:

  • Retention depth (hours) — how many hours to keep;
  • Max size (bytes) — the size ceiling.

When both are set, the stricter one wins. Cleanup runs once an hour: the depth deletes only fully expired hours, the size limit counts from the newest recordings towards the oldest.

The recording balances itself across the active disks: consecutive hours of one stream alternate between disks, neighbouring streams are spread evenly, the tracks of a multi-track stream are written in parallel. A disk moved to read-only is still read but takes no new data — that is how a disk is retired without losing the archive.

Reading

The archive is read by absolute time: an interval, an offset back from live (rewind) with a seamless join to live, a JPEG preview of the frame at a given moment. That is enough both for investigating an incident and for exporting a recording on request.

If the stream has subtitle extraction on, the extracted tracks are written alongside the video.

Checking the recording

The state of the recording is visible on the same tab: the archive window, the hours with data and the gaps in them, the archive size, the fragment write rates. What the deviations mean:

Sign What it means
DVR configured but not recording the stream is offline or the recording never started
the archive edge lags behind the current time the recording has stopped
the lower boundary stopped moving forward the cleanup is not running — a full disk is ahead
gaps: N h with a wide window there are holes in the archive: the stream fell over or recording was off
Archive write errors — data is being lost the archive is losing data right now, check the disk
Writing is degraded fragments are written slowly, with delay or collapsed — the storage is degrading

The last row is an early signal rather than a statement of loss: the share of slow writes grows before the errors appear.

What next