Differences

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

--- foundation:mediaserver [2025/12/20 01:04] – privacyl0st
+++ foundation:mediaserver [Unknown date] (current) – removed - external edit (Unknown date) 127.0.0.1
@@ 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.