Deleting Media Is a Playback Feature
A canonical artifact lifecycle makes storage cleanup safe enough for a live visual system.
A live visual library produces more than videos. It accumulates original sources, receiver-compatible conversions, analyzed segments, generated media, cache slices, temporary files, and the database records that connect them. At first, storage looks like a housekeeping concern. In a performance system it is part of playback correctness: deleting the wrong file can invalidate analysis, strand the queue, or remove the only copy that a render node can decode.
I addressed that by giving every managed file a lifecycle. A catalogue video is the logical work; its source, normalized versions, and segment caches are physical artifacts with recorded identity, state, producer, parentage, verification details, and fingerprints. The video points to exactly one canonical full-length artifact. Analysis and slice-cache records point back to the artifact they were derived from, so the system can distinguish an old filename from the actual media generation behind a result.
Normalization is a publication process rather than an in-place rewrite. If a source already satisfies the receiver contract, it can remain canonical without creating a redundant copy. Otherwise, the normalizer writes a temporary artifact, then checks codec and profile, pixel format, dimensions, frame rate, full decode, duration agreement, and a SHA-256 fingerprint. Only a complete result is atomically published and promoted. A replacement receives a new artifact path; the previous canonical file is not overwritten and remains selected if publication or database promotion fails.
That last rule is deliberately conservative. Filesystems and databases cannot be treated as one transaction, so failure recovery has to acknowledge the gap. Writer leases protect work in progress. Startup reconciliation repairs known interrupted deletion state, reconnects recognized outputs to catalogue records, and can recover a normalized-only video only after independently revalidating the file against persisted duration and the current receiver contract. A plausible filename is never enough evidence.
Visibility comes before cleanup. The storage inventory separates managed and unmanaged bytes, canonical media, superseded outputs, ready and stale cache slices, temporary artifacts, backups, and protected files. It reports missing records and identity changes as well as reclaimable space. Read endpoints serve a cached snapshot instead of recursively walking the media tree during an operator request; refreshes are serialized, and simultaneous requests share the result. That keeps an inspection tool from becoming surprise show-time I/O.
Deletion is intentionally a two-step protocol. First, an authenticated request creates an exact, expiring dry-run manifest. The plan is bound to an inventory revision and to each artifact's relative path, size, modification time, device and inode identity, and content fingerprint. The operator can inspect that manifest before a second request executes it with explicit confirmation. The API accepts cleanup modes and logical video IDs, not arbitrary filesystem paths.
Execution then assumes the plan may already be stale. Each candidate is checked again against catalogue state, writer leases, active playback, standby preparation, the queue, normalization, analysis, cache work, and persisted dependencies. A final canonical copy is protected unless the video has been deliberately retired under the configured policy. Source removal is opt-in and requires a current verified normalized canonical replacement. Unmanaged files, databases, backups, directories, symlinks, and anything whose identity changed after planning are refused.
On systems that support it, cleanup walks and opens the directory chain with no-follow semantics, holds file descriptors, compares the live device and inode to the manifest, hashes the opened file, and unlinks relative to the held parent directory. This narrows the race in which a path could be swapped between inspection and deletion. Before unlinking, the service commits deletion intent and an audit item. If the process stops in the narrow interval after that commit, reconciliation can distinguish an artifact that disappeared from one that remained and complete the run record honestly.
Cleanup failures degrade storage status but do not prevent the playback service from starting. That tradeoff reflects the priorities of the room: reclaiming disk is useful, preserving known-good media is essential. By making ownership, verification, protection, consent, and recovery explicit, I turned storage cleanup from a risky maintenance script into a bounded subsystem that the rest of Visualizer Stream can safely depend on.