How to Configure Live TV Recording Storage Without Filling App Data

Live TV recordings are large, durable media files; application data is small, latency-sensitive state needed to start and manage the server. When both share a container volume, a single recording can exhaust the space required for the database, logs, and upgrades.

The safe design gives recordings their own host dataset or share, mounts it into the container, and points the DVR setting at the container path. Transcode scratch space is a third data class and should not quietly fall back into the configuration volume.

Separate the Three Storage Roles

Identify the persistent configuration path, the recording library, and the transcode or timeshift workspace. Record their host paths and container paths in a small map; changing only the dashboard field is not enough if the container cannot see the destination.

Keep configuration on reliable storage with normal backup coverage. Put recordings on capacity-oriented storage that can absorb the expected write rate, and place transient transcode data where it cannot crowd out the database.

Estimate a worst-case recording, not an average episode. Multiply the tuner stream bitrate by the longest scheduled duration, add simultaneous recordings, and keep operational free-space headroom for filesystem and application behavior.

Mount a Dedicated Recording Destination

Create a host directory or dataset such as /srv/media/recordings and mount it into the container at a clear path such as /recordings. Use a bind mount or managed volume that persists when the container is recreated.

Match ownership and permissions to the UID and GID used by the Jellyfin process. A destination that is visible but not writable often produces a permission error and can tempt an operator to switch back to the default app-data path.

A community report of a recording path permission failure shows why visibility alone is not a sufficient test. Create and remove a small file as the container user before scheduling a real program.

Point DVR and Scratch Paths at Their Intended Volumes

In the Live TV or DVR settings, set the recording path to the container-visible recording mount, not the host path. If separate movie and series destinations are supported in your installed release, keep both under the same capacity-managed recording dataset unless you have a reason to split them.

Set the transcode path to a dedicated scratch mount with enough short-term capacity. Do not place recordings in the transcode directory: scratch data can be cleaned aggressively, while completed recordings are user data.

If you use post-processing, the Jellyfin post-processing behavior passes the completed recording path to the script. Make sure the script sees the same mounted path and cannot move a file into the application volume by accident.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Test Failure States and Add a Capacity Guardrail

Start a short manual recording, confirm that its size increases on the recording dataset, stop it, and play the result. Restart the container and repeat playback to prove that the mount is persistent rather than an anonymous container layer.

Set an alert on free bytes or percentage used for both the recording dataset and the app-data volume. Retention rules help, but they are not a substitute for an alert because failed cleanup, duplicate schedules, and unusually long events can defeat an estimate.

Back up the small configuration volume separately from bulky recordings. The Jellyfin decommissioning checklist provides a useful inventory model for distinguishing essential state from replaceable media-server components.