告別4個服務只留1個，Jellyfin 12憑一個插件讓我的小主機負載直降四成

我這臺迷你小主機里，四年間始終跑著四個獨立服務：一個管電影電視劇，一個管電子書，一個管漫畫，還有一個專門管有聲書。每個服務都有自己的端口、賬戶和元數據抓取邏輯。同一批磁盤上的文件，被四個進程各掃一遍，同一臺瘦小的 Debian 虛擬機硬是被拆成了四家“專營店”。

我嘴上說“術業有專攻”，可每次想從一章有聲書切到同名漫畫，都得關掉一個網頁、打開另一個網頁、重新登錄、等封面刷出來——這套操作在手機瀏覽器上是災難級別的體驗。

直到 Jellyfin 12 預覽版放出，我才找到理由把其中三個服務徹底停掉。不是這個流媒體平臺突然變萬能了，而是它的 Bookshelf 插件重構后給了我一個理由：用同一個登錄態、同一套文件夾結構，把視頻、電子書、漫畫、有聲書裝進同一個圖書館。在此之前，我對它的書籍支持是徹底放棄的——好幾年了，它在我眼里就是個純視頻服務器。

過去那種“四個 App 管四種介質”的痛，不是來自任何一個軟件做得不好。正相反，電子書管理器 Calibre-web 的網頁閱讀器對 epub 渲染快速且干凈，漫畫工具 Komga 翻頁進度從不丟失，有聲書管家 Audiobookshelf 能按章節快進、記住每本書的播放位置，這些都遠遠超過 Jellyfin 原生的書籍掃描能力。我從來沒有把這些庫映射進去，不是不想，而是它對書籍的元數據抓取實在太像半成品——作者頁面是空的，封面時有時無，掃描一個兩萬冊的 epub 文件夾常常能卡住整個庫刷新。我寧愿讓四個服務保持“老死不相往來”，至少它們各自穩定。

Jellyfin 12 這次最打動我的改動，恰恰就是元數據。Bookshelf 插件被重新打了地基，雖然它依舊需要手動去插件目錄添加，但一旦啟用，整個電子書、漫畫、有聲書的處理邏輯就肉眼可見地上了一個臺階。文件識別不再亂匹配：以前同名不同格式的電子書，比如《三體》同時有 epub 和 azw3，會被當成兩本書分別生成條目；現在它們歸到同一作品下，再按格式列出可讀版本。這對同時收藏 mobi、pdf 和 epub 的人來說，省掉的整理工作就不是一個下午能衡量的。

另一個提升是元數據抽取的密度和來源。過去的 Bookshelf 插件掃描后，作者頁經常只有名字，如今它會從書籍文件的嵌入信息里拽出作者簡介，再從已有媒體庫交叉引用同一作者的作品，形成一個能點進去看的作者主頁。雖然這還比不上 Calibre-web 那種可自定義數據源的靈活度，但對于只想“能看就好”的用戶，已經不構成遷移障礙了。

有聲書元數據的支持，成為我立刻拆掉 Audiobookshelf 的另一個原因。以前該平臺連有聲書的章節都分不出來，文件被當作一首首零散的 MP3，甚至連“記住上次聽到哪里”都做不到。這次 Bookshelf 插件直接利用音頻文件的內嵌章節標記，在網頁播放器里生成了可點擊的章節導航，播放進度也不再全局丟失，而是按書本記錄。我當然清楚這依然依賴社區插件的迭代，并非官方原生功能，但既然它就在同一個界面上、使用同一套文件夾和文件名規則，為什么還要單獨開一個服務去維護？

整個遷移過程比我預想的安靜得多。所謂“遷移”，其實沒有做任何文件拷貝或格式轉換。四個服務的根目錄本就在同一個 ZFS 數據集下，只是原先分別指向各自的專用掃描文件夾。我把插件安裝好，在書籍庫里添加上電子書、漫畫、有聲書這三個文件夾，然后觸發一次全量掃描。僅此而已。沒有重新整理作者名，沒有補全封面，甚至連音頻文件的書名標簽都沒改動。掃描跑完，大部分條目已經可以點開直接看。

Komga 讀進度那塊，我是比較過才決定關掉的。Bookshelf 插件現在支持在閱讀頁面記錄章節級和頁級進度，漫畫的縮放和左右翻頁也可以跟隨瀏覽器寬度調整。雖然它還無法像 Komga 那樣自動識別多個漫畫合集之間的故事線跳轉，但我并不需要那種程度的整理，能在手機上用同一個入口續看昨天的漫畫就已經足夠了。那些必須跨多部單行本才能看完的系列，我仍舊按文件夾排列，反正登錄后一眼能掃到。

四個服務變成兩個的最大回報，最先體現在小主機的日常負載上。Proxmox 里的 Debian 虛擬機原本常年內存占用在 6GB 以上，Jellyfin 的轉碼、Audiobookshelf 的音頻流、Komga 的漫畫圖片實時縮放各占一塊，再加上 Calibre-web 的 epub 渲染進程，系統幾乎喘不過氣。如今只留下它和 Calibre-web，日常內存占用跌到了 3.5GB 左右，CPU 平均使用率也降了四成。這臺曾被我視為“四駕馬車”的小主機，終于不必再左右橫跳了。