Plex
💡 快速導航
Plex 是我家用來集中管理影音內容的 media server。它的定位很簡單：把電影、影集和其他家庭影音整理成一個對家人友善的介面，讓電視、平板、手機都能用相同方式播放。
在這套 Home Lab 裡，Plex 跑在 TrueNAS 上。它和 Immich 類似，屬於「資料密集型」服務：媒體檔案很大、讀取頻率高，也可能需要轉碼，因此讓服務靠近主要儲存池會比跨主機掛載更穩定。
Important
這篇是公開筆記，所以不會記錄實際 LAN 位址、port、domain、Nginx Proxy Manager upstream、Plex token、claim token、媒體路徑、library 名稱、觀看紀錄、裝置名稱或 metadata database 內容。
🎯 我為什麼用它
家庭影音需要一個穩定入口
檔案直接放在 NAS 上當然也能播放，但家人要用得順，還是需要一個好懂的入口。Plex 解決的是「不用知道檔案在哪裡，也不用理解資料夾結構，就能打開 App 直接看」。
它對我最有價值的地方：
- 集中管理電影與影集
- 電視、手機、平板都有成熟 client
- 家人學習成本低
- metadata、海報、集數和播放進度比較直覺
- 服務搬移或儲存調整時，前端使用體驗不需要大改
它是娛樂層，不是核心資料庫
Plex 對生活品質提升很明顯，但它和密碼庫、照片庫、筆記同步不同。媒體 server 壞掉時通常不會造成核心資料遺失，但會影響家人每天的使用體驗。
所以我的維運重點是：讓它穩定、好找、好播放，而不是把架構做得過度複雜。
🧱 為什麼放在 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 最適合靠近媒體資料本身。影音檔案通常比一般文件大很多，如果 Plex 跑在另一台機器再透過 NFS / SMB 讀取，播放和掃描都會多一層延遲與故障點。
放在 TrueNAS 的原因
| 考量 | 說明 |
|---|---|
| 資料靠近性 | 媒體檔案直接在 NAS 儲存池上，Plex 不需要跨主機大量讀取 |
| 大檔案 I/O | 電影、影集和高 bitrate 內容會持續讀取大量資料 |
| 硬體能力 | TrueNAS 主機更適合處理轉碼或 metadata 掃描等負載 |
| 儲存可靠性 | ZFS pool、scrub、snapshot 和備份策略都圍繞主要資料設計 |
這讓整體架構更清楚：OMV 主要跑一般 App 與入口層；Plex 這類需要靠近資料和硬體能力的服務放在 TrueNAS。
📺 我的實際使用方式
目前 Plex 的使用方式很直接：
- 電影和影集集中在同一套媒體服務裡
- 家人使用電視、平板、手機直接播放
- 透過時間、片名、海報和集數整理內容
- 由 Plex 管理播放進度和跨裝置體驗
Plex 是那種「架好之後家人真的會每天用」的服務。它的價值不在於技術多炫，而是把原本散落在資料夾裡的影音內容變成一個容易瀏覽的家庭影音庫。
使用體驗
| 面向 | 實際感受 |
|---|---|
| 家人接受度 | Client 成熟，操作方式接近常見串流服務 |
| 跨裝置 | 電視、手機、平板體驗一致 |
| 維護成本 | 前期整理命名規則後，後續維護省很多 |
| 故障影響 | 不影響核心資料安全，但會影響娛樂使用體驗 |
🗂️ 媒體庫與命名規則
Plex 最容易踩坑的地方不是安裝，而是媒體命名和資料夾結構。
我的原則
- 匯入前先整理資料夾層級
- 電影與影集分開管理
- 影集保持清楚的季 / 集格式
- 不用臨時檔名長期保存媒體
- 一次整理一批，不在大量匯入後才回頭修
如果命名規則一開始很亂，Plex metadata match 會跟著亂。後續要修海報、集數、版本和錯誤識別時，花的時間通常比一開始整理命名還多。
Note
公開筆記不列出實際 library 名稱或媒體路徑。那些資訊可能透露家庭習慣、收藏內容或內部儲存結構。
⚙️ 轉碼與硬體能力
Plex 的理想狀態是 client 直接播放原始格式，也就是 Direct Play。這樣伺服器負擔最低，畫質也最不容易被重新壓縮。
但實際上仍可能遇到需要轉碼的情況：
- client 不支援原始影片格式
- 外部網路頻寬不足
- 字幕格式觸發轉碼
- 音訊格式不相容
- 裝置效能不足
TrueNAS 主機本身有較適合媒體處理的硬體條件，因此比把 Plex 放在較弱的 OMV 主機上更合理。不過公開筆記只描述架構考量，不聲稱特定硬體 passthrough 或 runtime mapping，因為這類細節需要以實際部署設定為準。
我會優先檢查
- 常用裝置是否能 Direct Play
- 字幕是否造成不必要轉碼
- 轉碼時 CPU / iGPU 負載是否正常
- 外部播放是否受頻寬限制
- 掃描媒體庫時是否影響其他服務
🌐 反向代理與存取邊界
Plex 可以在內網直接使用，也可以透過 Nginx Proxy Manager 做統一入口。公開筆記不列出實際 upstream、domain、LAN 位址或 port。
我的原則是：
- 入口由 NPM 管理，後端服務位置不要寫在公開文件
- 不把 raw service endpoint 當成公開資訊
- 若要對外使用，優先確認 HTTPS、登入保護和服務本身權限
- 不公開 Plex token、claim token、device id 或 request log
Plex 這類影音服務會有帳號、裝置、觀看行為和 metadata，因此公開內容越少越好。筆記只保留架構模型，不保留可直接連線或推測私有環境的細節。
💾 備份與還原
Plex 的備份要分成兩層看：媒體資料與 Plex app/config 資料。
| 類型 | 重要性 | 說明 |
|---|---|---|
| 媒體檔案 | 高 | 原始影音內容，容量大，備份成本最高 |
| Plex metadata / app data | 中高 | library、match 狀態、海報、觀看進度與設定 |
| Compose / app 設定 | 中 | 服務啟動方式與掛載關係 |
| Cache / transcode temp | 低 | 通常可重建，不應和核心資料同等備份 |
還原後檢查
- Plex 服務是否啟動
- 媒體庫是否仍能掃描
- metadata、海報與集數是否正常
- 常用 client 是否能播放
- Direct Play / transcode 行為是否符合預期
- NPM 入口是否仍正常
Plex 的 generated metadata 很多可以重建，但重建會花時間，也可能造成家人使用體驗下降。因此 metadata/app data 還是值得納入備份。
⚠️ 踩坑與維運原則
命名規則要先定
前期檔案命名和資料夾規則沒整理好，會直接影響片庫識別結果。這是 Plex 最常見也最容易低估的維護成本。
不要把媒體庫整理變成一次性大工程
我比較傾向先建立規則，之後每次新增內容就照規則處理。一次倒入大量未整理媒體，再回頭修 metadata，通常很痛苦。
升級要測播放，不只看 container
Plex 更新後不能只看服務有沒有啟動，還要測：
- Web UI 是否可進入
- 常用裝置是否能播放
- 字幕與音訊是否正常
- 外部入口是否正常
- 掃描與 metadata 任務是否正常
結論
Plex 是 Home Lab 裡很有生活感的服務。它不是最核心的資料安全元件，但它會直接影響家人每天看影片的體驗。
對我來說，Plex 的重點不是「能不能架起來」，而是媒體資料靠近儲存、命名規則清楚、播放路徑穩定、備份範圍合理。把它放在 TrueNAS 上，符合這套 Home Lab 的資料密集型服務原則。