Differences

This shows you the differences between two versions of the page.

--- foundation:mediaserver [2025/12/19 23:07] – created - external edit 127.0.0.1
+++ foundation:mediaserver [2025/12/20 01:04] (current) – privacyl0st
@@ Line 1: / Line 1: @@
+====== Plex Media Server (Physical Host) ======
+This page covers how to design and build the **physical machine** that runs **Plex Media Server** and **Unmanic** optimization services in the Trash Panda ecosystem.\\
+This guide is intentionally focused on **hardware selection and base OS installation only**. Application configuration is covered elsewhere.\\
+The target audience here is someone building their **first serious Plex environment** who wants:\\
+  * Fast, reliable playback
+  * Efficient transcoding
+  * Minimal day-to-day management
+  * Clear separation of concerns across the ecosystem
+===== Why a Dedicated Physical Media Server? =====
+Before talking about hardware, it’s worth answering a common question:\\
+> Why not just run Plex on the NAS or inside a VM?
+==== Plex as a NAS Application ====
+Running Plex directly on a NAS //**can**// work — until it **doesn’t**.\\
+Limitations commonly encountered:\\
+  * CPU class is optimized for storage, not transcoding
+  * iGPU capabilities are limited or absent
+  * Thermal and power constraints throttle sustained workloads
+  * Upgrades often require replacing the entire NAS
+For light, single-user setups this may be acceptable. For shared libraries and automation, it becomes a bottleneck.
+==== Plex Inside a VM ====
+Virtualizing Plex introduces a different set of tradeoffs:\\
+  * GPU passthrough adds complexity and fragility
+  * Transcoding performance becomes harder to reason about
+  * Storage and network paths lengthen
+  * Troubleshooting spans host + hypervisor + guest
+VMs shine for control-plane services. Plex is a **data-plane workload** — latency and throughput matter.
+==== Why Physical Wins Here ====
+A dedicated physical host:\\
+  * Provides **direct access to CPU and GPU resources**
+  * Delivers predictable transcoding performance
+  * Simplifies GPU usage
+  * Is easier to debug under load
+  * Can be upgraded incrementally
+In this ecosystem, Plex and Unmanic are the only services that truly benefit from bare metal — so they get it.
+===== Operating System =====
+==== Recommended OS ====
+  * **Ubuntu Server 24.04 LTS or later**
+Why Ubuntu:\\
+  * Excellent hardware and iGPU support
+  * First-class Docker ecosystem
+  * Long-term security updates
+  * Huge knowledge base
+==== Installation Guidance (High-Level) ====
+  * Minimal server install
+  * No desktop environment
+  * SSH enabled
+  * Automatic security updates enabled
+The OS should exist solely to support Plex and Unmanic.
+===== Resource Design Principles =====
+When sizing this machine, prioritize:\\
+. **Transcoding efficiency**\\
+. **Fast I/O for caching and processing**\\
+. **Thermal stability under sustained load**\\
+. **Headroom for spikes, not averages**\\
+The media lives on the NAS. This machine exists to **process and serve it**.
+===== CPU & GPU Recommendations =====
+This section intentionally adds a bit of **pragmatic subjectivity**. There is no single perfect answer for every build, but there //**are**// choices that consistently produce better real‑world results.\\
+The guidance below balances performance, efficiency, cost, and long‑term usability for Plex and Unmanic workloads.
+===== CPU Guidance (Brand‑Agnostic) =====
+For a dedicated Plex + Unmanic server, what matters most is:\\
+  * **Strong single‑thread performance** — Plex transcoding and Unmanic jobs often bottleneck here
+  * **Enough cores and threads to absorb concurrency** — Plex streams and Unmanic tasks can overlap
+  * **Predictable sustained performance** — throttling undermines reliability
+==== Core / Thread Recommendations ====
+  * **Minimum:** 4 physical cores / 8 threads
+        * Suitable for light use and limited concurrent streams
+  * **Recommended:** 6–8 physical cores / 12–16 threads
+        * The sweet spot for most home Plex environments
+  * **High‑Throughput:** 8+ cores / 16+ threads
+        * Appropriate for heavy sharing or aggressive Unmanic pipelines
+Once you are past ~6 quality cores, transcoding performance is driven far more by **hardware acceleration** than raw CPU power.
+==== Intel vs AMD (Objective Framing) ====
+Both Intel and AMD CPUs can work extremely well in this role:\\
+  * Intel platforms traditionally pair cleanly with media workloads
+  * AMD platforms often deliver excellent core density and efficiency
+Rather than chasing a brand, focus on:\\
+  * Modern architecture
+  * Strong single‑core boost behavior
+  * Adequate PCIe support for a discrete GPU
+===== Why a Discrete GPU (Over Integrated Graphics) =====
+While integrated graphics //**can**// work, this guide **recommends a discrete GPU** for most builders.\\
+Objectively, discrete GPUs provide:\\
+  * Dedicated video encode/decode engines
+  * Higher concurrent transcode capacity
+  * Better thermal isolation from the CPU
+  * More predictable performance under sustained load
+Integrated GPUs share power and thermal budgets with the CPU. Under real‑world Plex and Unmanic usage, this frequently becomes the limiting factor.
+===== Discrete GPU Options =====
+The goal is not maximum shader performance — it is **efficient, reliable video processing**.\\
+==== Option A — Midrange NVIDIA (e.g., RTX 3060 / RTX 4060) ====
+**Pros**\\
+  * Excellent NVENC / NVDEC support
+  * High concurrent transcode capacity
+  * Mature Linux drivers
+  * Very strong performance‑per‑watt
+  * Excellent Unmanic acceleration potential
+**Cons**\\
+  * Higher upfront cost
+  * Overkill for single‑user or light workloads
+**Best for:** Builders who want headroom, future growth, and minimal compromise.
+==== Option B — Value NVIDIA (e.g., GTX 1660 Super) ====
+**Pros**\\
+  * Lower cost
+  * Solid hardware transcoding support
+  * Efficient and reliable for common codecs
+**Cons**\\
+  * Fewer concurrent streams
+  * Older generation feature set
+**Best for:** 1080p‑heavy libraries with modest concurrent usage.
+===== AMD Discrete GPUs =====
+Modern AMD GPUs include capable video engines and are increasingly well supported by Plex.\\
+**Pros**\\
+  * Strong price‑to‑performance ratio
+  * Efficient for batch workloads
+**Cons**\\
+  * Hardware acceleration support can vary by driver and Plex version
+  * May require additional validation
+AMD GPUs can be an excellent choice if you are comfortable verifying codec support for your specific workload.
+===== Summary Guidance =====
+| **Component** | **Recommendation**                           |
+| ------------- | -------------------------------------------- |
+| CPU           | 6–8 physical cores / 12–16 threads           |
+| GPU           | Discrete GPU (midrange NVIDIA preferred)     |
+| RAM           | 16–32 GB                                     |
+| Storage       | Fast local NVMe/SSD for OS and cache         |\\
+Discrete GPUs reduce guesswork, isolate thermals, and deliver a smoother Plex experience — especially as libraries and user counts grow.
+===== Memory (RAM) =====
+Plex itself is not memory-hungry, but **cache is king**.\\
+==== Recommended RAM ====
+  * **Minimum: 16 GB**
+  * **Recommended: 32 GB**
+This allows:\\
+  * Large filesystem cache
+  * Smooth concurrent transcodes
+  * Headroom for Unmanic processing bursts
+Excess RAM is rarely wasted in this role.
+===== Storage Configuration =====
+This system should use **local NVMe SSDs only** for the OS, applications, and all transient workloads.\\
+Media libraries live on the NAS. Local storage exists to make everything **fast** and **responsive**.\\
+==== Recommended Storage Layout ====
+For best results, use **two separate NVMe SSDs**:\\
+. **OS / Application Drive**\\
+. **Transcoding & Cache Drive**\\
+This separation improves performance, simplifies troubleshooting, and reduces wear-related surprises.
+==== OS / Application NVMe ====
+  * NVMe SSD
+  * **500 GB minimum**
+  * Hosts:
+        * Ubuntu OS
+        * Docker runtime and images
+        * Plex Media Server
+        * Unmanic
+        * Logs and system packages
+This drive benefits from fast random I/O and consistent latency. NVMe ensures system responsiveness even under load.
+==== Transcoding & Cache NVMe ====
+  * Dedicated NVMe SSD
+  * **500 GB–1 TB recommended**
+  * Used for:
+        * Plex transcode directory
+        * Unmanic processing and working directories
+        * Temporary scratch data
+Why this matters:\\
+  * Transcoding is extremely write-heavy
+  * Unmanic workloads are bursty and I/O intensive
+  * Separating this workload protects the OS drive
+  * Performance remains consistent even during heavy processing
+If you can only afford one NVMe drive initially, this configuration still works — but two drives is the **recommended and future-proof layout**.
+==== What Not to Store Locally ====
+  * Media libraries
+  * Long-term downloads
+  * Backups
+Those belong on the NAS.\\
+Fast local NVMe storage is one of the highest-impact upgrades you can make to a Plex server. It directly improves startup time, transcode speed, and overall system responsiveness.
+===== Networking Requirements =====
+The media server should have **two physical NICs**:\\
+. **NFS VLAN NIC**\\
+  * High-throughput access to the NAS
+  * Jumbo Frames enabled
+. **DMZ VLAN NIC**\\
+  * Plex remote access traffic
+This mirrors the segmentation strategy used across the ecosystem and keeps storage traffic isolated.
+===== Reliability and Power Considerations =====
+  * Use a quality power supply
+  * Ensure adequate cooling
+  * Favor cases with good airflow
+Transcoding is sustained work. Thermal throttling undermines everything else.\\
+If possible:\\
+  * Place the server on a UPS
+  * Enable clean shutdown on power loss
+===== Final Thoughts =====
+This machine is the **engine** of the entire Plex experience.\\
+A well-built physical media server:\\
+  * Makes Plex feel instantaneous
+  * Handles transcoding quietly and efficiently
+  * Reduces complexity everywhere else
+By dedicating hardware to Plex and Unmanic, you remove guesswork, isolate risk, and create a system that simply does its job — day after day.\\
+That reliability is the real optimization.