The media stack serves a personal library built mostly from owned DVDs and Blu-rays. Jellyfin is the main user-facing piece, with supporting containers for metadata, organization, and maintenance.
Role In The Lab
The media stack is both a useful household service and an architecture exercise. It brings together storage, containers, network mounts, hardware encoding, client compatibility, remote access, updates, and backup prioritization in one system that gets used often enough to expose rough edges.
That daily use makes it a better learning environment than a demo workload. Playback either works on the devices people use or it does not.
Current Pattern
The stack is split between compute and storage. Media files live on the NAS, while the media LXC handles the containers and hardware-encoding side of the workload. The storage is mounted into the media environment through a network share and bind mount pattern.
This split keeps large storage on the NAS while letting Proxmox handle the compute and passthrough needs.
Services
Jellyfin is the service that actually gets used day to day. Radarr and Sonarr help with metadata and library organization.
The media LXC is also where camera/object-detection workloads can live, because those workloads have similar hardware-encoding requirements.
Operating Notes
The useful maintenance boundary is between the service configuration and the media files. Container definitions, LXC configuration, and application state need a recoverable path. The library is much larger and largely replaceable, so it does not receive the same backup priority as photos, personal files, or system configuration.
This also influences updates. Media clients and server versions can expose compatibility problems that are not obvious from a release note, so changes are more useful when they are reviewed and reversible rather than automatically applied everywhere.
Backup Tradeoffs
The LXC and service configs are backed up through the Proxmox backup path. The media library itself is large and lower priority than photos, personal files, and system backups, so it is not treated as a top off-site backup target right now.
The main lesson is that a media stack is a surprisingly useful architecture exercise. It touches containers, NAS storage, network mounts, GPU/passthrough, client compatibility, remote access, update routines, and the rough edges of open-source user experience.
It is also a good reminder that not every large dataset deserves the same backup treatment. The service configuration and playback environment matter more than treating a massive, replaceable media library like irreplaceable personal data.
Lessons
Separating compute from storage has made the system easier to reason about, but the boundary introduces its own dependencies: mounts need to be available, permissions need to stay understandable, and hardware acceleration needs to survive changes to the host and container.
The most useful design decision is not a particular application. It is assigning recovery priority based on what would actually be difficult to replace.
Next Pass
The next pass is better service documentation: record the mount and hardware-encoding assumptions in public-safe terms, keep a short playback troubleshooting checklist, and prove that the service configuration can be restored without treating the whole media library as critical backup data.