VPS 資料庫遷移 Jellyfin 自架媒體伺服器 .NET 10 FFmpeg

Jellyfin 12.0 首次開機就把資料庫重寫、.NET 10 逼所有外掛重編:這一版該不該升,看清楚幾件事再動手

Jellyfin 12.0 在 2026 年 9 月 7 日釋出,是專案史上動作最大的一次改版:版號從 10.11 直接跳到 12.0、資料庫 schema 在第一次開機被重寫、書櫃跟漫畫收進 server core、伺服器換 .NET 10 讓第三方外掛全部要重編。這篇拆解升級路徑上真正的陷阱。

Jellyfin 12.0 於 2026 年 9 月 7 日推出,開發者把版號從 10.11 直接跳到 12,第一次開機就會把資料庫 schema 重寫一輪。這不是那種 patch note 三行講完的小改版,而是把版本編號規則、書櫃支援、外掛 ABI、transcoding pipeline 全部重排的一次大改。自架 Jellyfin 給家裡人或社群用的管理者,這次升級的作業成本比過往任何一次都高——但同時這也是幾年來 Jellyfin 第一次值得認真對待的版本。

中文技術圈目前只有簡單「發佈了」的翻譯稿,實際踩過升級才會踩到的雷還沒有人整理。以下針對自架者角度拆一次。

版號從 10.11 跳到 12.0 不只是位數換位

Jellyfin 過去七年一路是 10.x.y,這次把「10」這個永遠不會變的前綴拿掉,變成 12.0。開發者的解釋是 10 這個 major 從來沒動過,實質上大家看的是第二個位數,所以維持表面上的三段版號沒意義。從 12.0 開始,第一個數字才是 major、第二個是 minor/patch。

這個改法對自架者的意義是:往後的 major bump 都要當作 major bump 對待。過去很多人把 Jellyfin 升級當背景更新處理,因為十年來版號從沒到過 11。以後只要看到第一個位數變,就要按照官方指示的方式備份、規劃維護窗口。這一版的路徑本身就把這件事教訓了一遍:從 12.0 之後,任何 major bump 都會伴隨資料庫改動。

資料庫在第一次開機就自我重寫

實際升級 12.0 最容易翻車的地方就是資料庫。這一版把 playlist 跟 collection 的內容從序列化欄位搬到一個叫 LinkedChildren 的新表,每個曲目、每部影片是一列。過去 Jellyfin 把整個 playlist 序列化成一個大字串塞在一欄,改一個項目就重寫整個列表,長 playlist 打開跟編輯都會卡。新的 schema 讓分頁載入變可能,也不用因為刪一首歌重寫上百 KB 的資料。

代價是首次開機必須跑 migration。Jellyfin 12.0 只支援從 10.10.7 或任何 10.11.x 直接升,中間跳版不接。升級後第一次進 server,backend 會執行 schema 改寫、合併重複的音樂 artist、清掉 orphaned extras、修 owner 關係,這段過程可能跑幾分鐘到幾十分鐘,看 library 大小而定。強制中斷或斷電就變成無法回頭的狀況——12.0 沒有 downgrade 路徑,只能靠升級前的備份還原。

容器化部署有一個容易漏掉的選項:jellyfin --mode MigrateSystem 可以在不啟動主 server 的情況下先把 migration 跑完,比較適合寫成 init container 或 pre-start hook。這個 flag 官方沒有在部落格文首強調,但實務上是把升級跑穩的關鍵——把 migration 從服務啟動流程裡拆出來,就能避免容器編排系統看到 startup 太久直接 kill 掉容器、造成升級到一半被打斷。

書櫃跟漫畫直接進 server core

Bookshelf 這個第三方外掛過去負責幫 Jellyfin 認 EPUB、CBZ、CBR、PDF,但它長年卡在功能沒補齊、metadata 抓不乾淨的狀態。12.0 把 Bookshelf 的核心功能吃進 server 本體:OPF 檔跟 ComicInfo.xml 的 metadata 直接讀、EPUB 跟漫畫封面自動產生、PDF 跟壓縮包的頁數會抓、audiobook 章節能切、ISBN external ID 進到 metadata provider chain。

檔名解析也重寫過。過去 Bookshelf 對「作者 - 系列 (年份) 集數」這種命名很挑,這一版容錯度拉高。web client 那邊補上 Modern book library layout 跟一個新的閱讀器:EPUB 字級可調、翻頁進度、以作者為主軸的瀏覽。

這件事對臺灣使用者的意義是實際的。過去要在 Jellyfin 上做輕小說跟漫畫 library,穩定性一直不夠好,很多人退回 Komga 或 Kavita 專攻書。12.0 把 server core 的能力補到跟這些專用工具接近,代價是要接受 Jellyfin 一站式媒體伺服器的重量。同時跑影片、音樂、書的自架者,這一版第一次可以認真評估把 Komga 收掉。

.NET 10 把外掛生態按下 reset

Server 這一版換到 .NET 10。ABI 不相容,所有第三方外掛都要重編。升級前一定要先把非官方 repo 的外掛全部關掉——12.0 不會拒絕載入舊 dll,但會在載入時 crash 或行為異常,反過來汙染 log 難以定位。

官方 stable repo 的外掛都已經有 12.0 版本。第三方外掛作者更新腳步不一,Bookshelf 這種因為功能進了 core 而確定不會有 12.0 版;其他常見的 LDAP 認證、Trakt.tv 同步、字幕外掛,升級時要一個一個確認狀態。

比較實際的升級順序建議是:先在 staging 或非正式的 Jellyfin instance 跑一輪,把外掛依賴清冊列出來,確認每個外掛都有 12.0 相容版本或有替代方案,再排正式環境。整個節奏跟過去 Jellyfin 更新那種「按下去讓它跑」是完全不同的等級。

FFmpeg 8.1 帶來 HLG tone-mapping 準確度

Transcoding 這一塊換到 FFmpeg 8.1。CUDA transposing、OpenCL scaling 跟 tone-mapping 有優化,但更值得注意的是 HLG(Hybrid Log-Gamma)tone-mapping 換成 BT.2446 Method B EOTF。白話講:把 HDR 素材轉成 SDR 給不支援 HDR 的裝置播的時候,色彩跟亮度比過去準。

Trickplay(快轉時的縮圖預覽)也改成掃描 library 時直接抓現有檔案,不再每次都重生成。這對硬碟已經放了幾 TB 影片、每次升級 Jellyfin 就要重跑 trickplay 一晚上的自架者,是體感差別最明顯的一項。

升級前必須做的檢查清單

實務上這一版升級要做的事情:

第一,備份 config 資料夾。這一版沒有 downgrade 路徑,資料庫 migration 是單向的。

第二,檢查使用者名稱。12.0 把 username 改成 case-insensitive,如果 library 裡同時存在 admin 跟 Admin,migration 會炸。改名成不衝突後再升。

第三,把第三方外掛全關掉。升完再一個一個補回來,確認每個都有 12.0 相容版本。

第四,legacy /emby/ 跟 /mediabrowser/ URL 路由這一版拿掉了。用老 Emby-era client 的用戶要換到新版 Jellyfin client,不然升完直接連不上。

第五,SSL/TLS 內建支援還在,但官方明確建議走 reverse proxy——Caddy、Nginx、Traefik 都是合理選擇。用內建 TLS 的環境可以趁這波規劃遷移。

該不該升 12.0 這件事有明確答案

如果 Jellyfin instance 只是自己家用、影片為主、外掛用量少,12.0 值得升——安全修補、transcoding 效能、資料庫效能都是純加分。書櫃跟漫畫用得多的話也是明顯的升級誘因。

反過來,Jellyfin 上跑著幾十上百個使用者、外掛依賴重(LDAP、第三方 metadata provider、自定分類邏輯)的環境,這一版建議延一到兩個月,等外掛作者跟上。10.11.x 分支還會維持一段時間的安全更新,不用急著在第一週跳。

Jellyfin 這樣規模的專案能一次做這麼大的版本躍升,某種程度上代表它已經走出「Emby fork」的階段,開始有自己的技術路線圖。對長期打算自架的人,這是好消息。

自架 Jellyfin 對主機的最低門檻是 4 vCPU、8 GB RAM 起跳,硬體轉碼看 GPU、library 規模看儲存跟 IOPS。NCSE Network 的臺灣 VPS 用 Intel Gold CPU 搭 NVMe SSD、機房落在是方電訊,對這種要接家裡跟社群使用者的媒體伺服器,網路延遲跟 uplink 頻寬都比走境外方案穩定。有規劃 Jellyfin 12.0 遷移或想找適合的自架主機,可以到 NCSE Network 看服務規格或聯繫團隊討論。

需要穩定的雲端主機?

NCSE Network 提供企業級 VPS,7 天免費試用,臺灣是方電訊機房,99% SLA 保證。

查看 VPS 方案 →