Recording padding and programme coverage

Recording padding expands the requested capture interval before and after a listed programme, trading additional source and storage use for coverage of timing uncertainty.

A programme listing says 20:00–21:00. The broadcast might begin slightly early or continue beyond the listed end.

Recording padding requests extra capture around the nominal interval. It adds a fixed margin; it does not discover the programme’s actual boundaries.

Draw the capture and programme intervals together

Use two minutes of start padding and five of end padding:

{
  "listed": {"startMinute": 0, "endMinute": 60},
  "padding": {"beforeMinutes": 2, "afterMinutes": 5},
  "actualProgramme": {"startMinute": -1, "endMinute": 68}
}

Minutes are measured from 20:00 on the same date. The requested capture is [-2,65), or 19:58–21:05.

The actual programme runs [-1,68), lasting sixty-nine minutes. Capture includes its first sixty-six minutes and misses the final three. One captured minute precedes the actual programme.

The original listed, padded-capture and actual-programme intervals show the captured content and missing three-minute tail.

That is a useful improvement over recording only [0,60), but it does not provide complete coverage in this case.

If the programme instead ends at minute 64, the same padding contains it. The result depends on the actual uncertainty, not simply on padding being enabled.

Margins have a reason and a cost

Start padding can cover an early broadcast and leave room for acquisition to become usable. End padding can cover a late finish. Those are different uncertainties and need not use equal values.

Sports and live events can have a larger uncertain ending than a fixed-length recorded programme. Even a large chosen margin remains finite.

An updated guide can provide a better nominal interval. Extending padding indefinitely is not a substitute for correcting a systematically wrong time conversion or station mapping.

“Requested” is not always “available”

Emby documents default start/end padding with per-recording choices. Its public timer contract also distinguishes padding values and whether pre/post padding is required.

The implementation decides how optional margins interact with competing recordings. If a margin is dropped to resolve a conflict, compare the actual captured interval with the programme before deciding whether any wanted material was lost.

A required margin expresses a stronger request. It still cannot make an unavailable source or unwritable destination work.

Back-to-back programmes on one station can share a continuous acquisition only through a route that implements that behavior. The two output recordings and their owners still need the appropriate individual lifetimes.

Added minutes consume actual resources

In a constant ten-Mbit/s payload exercise, sixty minutes require 4.5 GB of media bytes. Adding the two/five-minute margins increases that to 5.025 GB, an extra 525 MB.

These are decimal units and exclude other overhead. The acquisition also lasts seven minutes longer.

At schedule boundaries, the extra source lifetime can overlap another request even when the nominal programmes do not. Recording conflicts shows that overlap explicitly.

See Also

References