Recording retention and storage ownership

Recording retention determines which captured artifacts remain under count, protection and active-use policies, while successful storage reclamation remains a separate outcome.

A rolling recording collection keeps recent episodes while making room for new ones. Retention expresses which recordings should remain; it also needs a reliable way to turn deletion decisions into actual storage changes.

A “keep three” preference is only fully defined once ordering, protected items and active uses have been addressed.

A count needs a declared policy

Use this original inventory, ordered from oldest to newest:

Recording Size Protected Active use
R1 2 GB Yes No
R2 3 GB No No
R3 4 GB No No
R4 3 GB No Yes
R5 5 GB No No

For this teaching exercise, keep the newest three, retain protected items additionally, and defer removal while an item has an active use.

The newest set is R3, R4 and R5. Adding protected R1 produces four retained items. R2 is the only current deletion candidate.

The initial collection contains seventeen decimal GB. If removing R2 successfully reclaims its three GB under the declared storage model, fourteen remain.

This policy permits exceptions to exceed the nominal count. A different implementation can define how protected items contribute to its limit; the setting name alone does not choose that rule.

Retention and recording eligibility are separate

A series rule can want an airing and later apply retention to its completed result. Deleting an old artifact does not inherently delete the continuing series intent.

It can, however, change a later “skip episodes already in the library” decision. A now-absent episode may be eligible again under that policy.

A retained history of previous capture and a presently available file are also different inputs. A recorder might use either when suppressing repeats according to its configured rules.

A candidate is not reclaimed capacity

The selection stage identifies R2. The removal stage still needs to succeed against the actual destination, permissions and current ownership.

An active viewer, post-processing job or other open use can prevent or defer removal on some storage paths. Another path can remove a name while an existing open use continues retaining storage. Those behaviors depend on the filesystem and access contract.

The important observations are therefore distinct:

Observation What it establishes
Selected for deletion Policy chose the item
Removed from library display Catalogue visibility changed
Storage operation succeeded The particular removal operation completed
Available space increased Capacity was actually reclaimed on that volume

Filesystem allocation, shared extents, delayed reclamation and storage reservations can make byte accounting differ from a sum of displayed file sizes.

Coordinate the artifact’s owners

Post-processing can temporarily retain an original and a replacement together. Retention should apply to the intended artifact state rather than deleting an input while its owner still needs it.

The library also needs a consistent view after removal. A stale item can remain listed even when its path has disappeared; rescanning/catalogue reconciliation addresses that association.

Emby exposes recording retention concepts in its public series/timer contracts. A rolling collection deliberately removes older content under a policy; a backup has the different purpose of preserving recoverable copies.

See Also

References