# System and media disk space — player 4.2.22

The dashboard shows two live pie charts: **System disk** and **Data / media disk**.
The system query uses the service working directory (equivalent to `df .`);
the media query uses `DCP_PLAYER_MEDIA_ROOT` (equivalent to `df <media-root>`).
On appliance installations the media root is normally under `/media`, so its
values agree with `df /media`. Mount point, device and filesystem labels identify
the volume actually used, including symlinks and dedicated drives.

Charts show used, available and filesystem-reserved space in GiB/TiB. These are
live filesystem statistics, independent of package count or indexed content.
Used and available match `df`; reserved space explains why their sum can be
smaller than total. The dashboard refreshes through its normal status polling.

If both directories have the same filesystem device identity, the dashboard
labels them **Same disk · shared space** and shows identical usage values on both
charts. Different partitions/filesystems on one physical drive have independent
space accounting and are reported separately. An inaccessible/missing directory
shows **Disk space unavailable**; a missing media root does not conceal system
space or invent a fallback volume. No disk discovery, mount, format or permission
change is performed by a status read.

Authenticated `GET /api/status` includes `storage` with `system`, `media`,
`same_filesystem` and `sampled_at_utc`. Each disk has `path`, `mount_point`,
`device`, `filesystem`, `total_bytes`, `used_bytes`, `free_bytes` (available to the
player) and `reserved_bytes`. Unavailable disks and indeterminate shared status
are null. `GET /api/player/v1/status` includes the same storage snapshot and
retains legacy `storage.total_bytes` and `storage.free_bytes` for the media disk
when available. The OpenAPI contract describes these additive fields. Disk
inventory is not included in anonymous discovery.

On the qualification player, `/dev/sda2` holds the system and `/dev/sdb1`, labelled
`DCP_Data`, is mounted at `/media` through its UUID in `/etc/fstab`. Initial checks
found approximately 439 GiB system capacity and 2.7 TiB media capacity. The
`dcpplayer` account could read, traverse and write the media directories; a
temporary create/remove test passed. The original dashboard used a fixed
128 GB package-count estimate, so it did not reflect the installed media drive.
No ownership or permission repair was required.

Reproduce backend qualification with `go test ./cmd/dcp-player-service -run
TestStorage` from `player-service`. Tests compare readings with actual `df`, check
shared paths/symlinks, separate tmpfs storage, escaped mount names/path boundaries,
missing media and authenticated status/legacy-field compatibility. Browser
qualification uses `TestTableBrowserFixture` with
`tests/disk_storage_browser_test.cjs` to check two charts, shared values, missing
media and mobile layout in an isolated fixture.

## Media storage consistency and recovery

In **Config → System Details**, an administrator can select **Check media storage**.
The background check inspects configured storage roots and, when the media root
is on a dedicated `/media` mount, the whole `/media` volume so dropped deliveries
are found. It also checks configured KDM storage. `lost+found` is excluded, nested
filesystems and symlinks are skipped, and database/identity directories are
protected. The report lists the actual scan roots.

Checks cover catalogue paths and indexed sizes, read access, writable/traversable
storage roots, shared system/media storage, low available space, partial transfers
and unreferenced files or DCP directories. Existing package/materialised trees
are protected as a unit, including their control documents and markers. This is
a filesystem/catalogue check, not a cryptographic hash or KDM-playability audit.
Unreadable catalogue/SPL data or an incomplete scan disables all actions. The
metadata scan is limited to two minutes, 100,000 entries and 2,000 findings.

Recoverable findings offer **Ingest DCP**, **Import KDM** or **Import SPL**.
DCPs already in the package root are indexed in place; deliveries elsewhere are
copied into managed packages through normal ingest before integrity/indexing. KDMs use
recipient-aware existing-file import; SPLs use the native parser and item
validation. Existing SPL UUIDs are never overwritten. Recovery runs as a durable
background job and requires ingest licensing. It does not start playback.

Unreferenced content can be permanently deleted only after explicit confirmation.
“Unreferenced” means the player cannot find catalogue references; it does not mean
the file is unwanted. Whole-DCP deletion removes its directory. Before either
action the player rechecks file identity/size/time, filesystem identity and current
references. Changed candidates, symlinks, incomplete reports, playback and active
background jobs block actions. Root-anchored deletion cannot escape the selected
storage root. The check itself never imports, deletes, mounts or fixes permissions.

The report is retained for the current service session. Check again after a
restart or external filesystem change. Operational logs record deletions and
recovery outcomes. UI endpoints are authenticated administrator operations:
`GET/POST /api/storage/check` and `POST /api/storage/actions`. An action body has
`check_id`, `finding_id` and `action` (`ingest` or `delete`); there is no arbitrary
path deletion endpoint.