Plex
๐ก Quick Navigation
Plex is the media server I use to centralize home video content. Its job is simple: organize movies, shows, and other home media into a family-friendly interface that works consistently across TVs, tablets, and phones.
In this Home Lab, Plex runs on TrueNAS. Like Immich, it is a data-heavy service: media files are large, read patterns are frequent, and transcoding may be needed. Keeping the service close to the primary storage pool is more stable than pulling large media files across hosts.
Important
This is a public note, so it does not include the real LAN address, port, domain, Nginx Proxy Manager upstream, Plex token, claim token, media paths, library names, watch history, device names, or metadata database contents.
๐ฏ Why I Use It
Home media needs one stable entry point
Media files can be played directly from a NAS, but that is not smooth enough for family use. Plex solves the problem of โopen the app and watchโ without needing everyone to understand file paths or folder structure.
What I value most:
- centralized movie and show management
- mature clients for TV, phone, and tablet
- low learning curve for family members
- intuitive metadata, posters, episodes, and watch progress
- backend moves or storage changes do not need to change the user-facing experience
It is an entertainment layer, not a core database
Plex improves quality of life, but it is different from a password vault, photo library, or note-sync system. If the media server breaks, it usually does not mean core data is lost, but it does affect daily household usage.
My operational goal is therefore stability and usability, not unnecessary architectural complexity.
๐งฑ Why It Runs on TrueNAS
flowchart TD TV[TV / Tablet / Phone] --> NPM[Nginx Proxy Manager] NPM --> PLEX[Plex<br/>TrueNAS] PLEX --> MEDIA[(Media Dataset<br/>ZFS Pool)] PLEX --> META[(Plex App Data / Metadata)] MEDIA --> BK[OMV Backup Target]
Plex makes the most sense close to the media data itself. Video files are much larger than normal documents. If Plex runs on another host and reads everything through NFS / SMB, playback and scanning add another layer of latency and failure points.
Why TrueNAS makes sense
| Consideration | Notes |
|---|---|
| Data locality | Media files live directly on the NAS storage pool, so Plex does not need heavy cross-host reads |
| Large-file I/O | Movies, shows, and high-bitrate content continuously read large amounts of data |
| Hardware capability | The TrueNAS host is better suited for transcoding or metadata scanning workloads |
| Storage reliability | ZFS pool, scrub, snapshots, and backup strategy are designed around primary data |
This keeps the architecture clear: OMV runs general apps and the entry layer, while Plex stays on TrueNAS as a service that needs to be close to data and hardware resources.
๐บ How I Actually Use It
Current Plex usage is straightforward:
- movies and shows are centralized in one media service
- family members watch from TV, tablet, and phone
- content is organized by title, poster, season, and episode
- Plex manages watch progress and cross-device experience
Plex is one of those services that people actually use every day once it is set up well. Its value is not technical flash. Its value is turning folders of media files into a browseable home media library.
Usage experience
| Area | Practical result |
|---|---|
| Family adoption | Mature clients make it feel close to common streaming services |
| Cross-device use | TV, phone, and tablet usage is consistent |
| Maintenance cost | Good naming rules early reduce later cleanup work |
| Failure impact | Does not usually threaten core data safety, but affects entertainment usage |
๐๏ธ Media Library and Naming Rules
The easiest Plex mistake is not installation. It is media naming and folder structure.
Rules I follow
- Organize folder hierarchy before importing
- Keep movies and shows separate
- Use clear season / episode formatting for shows
- Do not keep temporary filenames long-term
- Fix one batch at a time instead of importing everything and cleaning later
If naming is messy at the beginning, Plex metadata matching becomes messy too. Fixing posters, episodes, editions, and incorrect matches later usually takes longer than organizing filenames first.
Note
Public notes do not list real library names or media paths. Those details can reveal household habits, collection details, or internal storage structure.
โ๏ธ Transcoding and Hardware Capability
The ideal Plex path is Direct Play: the client plays the original file without server-side transcoding. That minimizes server load and avoids unnecessary quality loss.
In practice, transcoding can still happen when:
- the client does not support the original video format
- external bandwidth is limited
- subtitle format triggers transcoding
- audio format is incompatible
- the device is not powerful enough
The TrueNAS host has better media-processing characteristics, so it makes more sense than placing Plex on the weaker OMV host. This public note describes the architectural reason only; it does not claim a specific hardware passthrough or runtime mapping because those details should be verified from actual deployment config.
What I check first
- Common devices can Direct Play
- Subtitles are not causing unnecessary transcoding
- CPU / iGPU load looks reasonable during transcode
- External playback is not bandwidth-limited
- Library scanning does not disrupt other services
๐ Reverse Proxy and Access Boundary
Plex can be used directly on the LAN or through Nginx Proxy Manager as a unified entry point. This public note does not list the real upstream, domain, LAN address, or port.
My rules:
- NPM manages the entry point; backend service location does not belong in public docs
- Raw service endpoints are not public information
- For external use, verify HTTPS, login protection, and Plexโs own permissions first
- Do not publish Plex tokens, claim tokens, device IDs, or request logs
Media services include accounts, devices, watch behavior, and metadata, so public notes should stay minimal. The note keeps the architecture model, not directly usable connection details.
๐พ Backup and Restore
Plex backup needs two layers: media data and Plex app/config data.
| Type | Importance | Notes |
|---|---|---|
| Media files | High | Original video content; large and expensive to back up |
| Plex metadata / app data | Medium-high | Library state, matching, posters, watch progress, and settings |
| Compose / app settings | Medium | Startup method and mount relationships |
| Cache / transcode temp | Low | Usually rebuildable and should not be treated like core data |
Post-restore checks
- Plex service starts
- Libraries can still scan
- Metadata, posters, and episodes look correct
- Common clients can play content
- Direct Play / transcode behavior matches expectations
- NPM entry point still works
Much of Plex generated metadata can be rebuilt, but rebuilding costs time and may degrade household experience. Metadata and app data are still worth backing up.
โ ๏ธ Pitfalls and Operations Principles
Set naming rules first
Early file naming and folder structure directly affect library recognition. This is the most common Plex maintenance cost and one of the easiest to underestimate.
Do not turn library cleanup into one giant migration
I prefer to establish the rules first, then handle new content consistently. Importing a large messy library and fixing metadata afterward is usually painful.
Test playback after upgrades, not just the container
After Plex updates, checking whether the service started is not enough. I also test:
- Web UI access
- playback on common devices
- subtitles and audio
- external entry point
- scanning and metadata jobs
Conclusion
Plex is one of the most lifestyle-visible services in the Home Lab. It is not the most critical data-safety component, but it directly affects the daily media experience at home.
For me, the point of Plex is not just getting it running. The point is keeping media close to storage, using clear naming rules, keeping playback paths stable, and backing up the right parts. Running it on TrueNAS fits the same data-heavy-service principle used elsewhere in this Home Lab.
Further reading: Home Lab Overview, TrueNAS, Nginx Proxy Manager