Glance分叉3年后，這個開發者用2.0版本把自動更新做成了后

開源媒體管理工具的圈子里，fork（分叉）項目活得比原版好的例子不多。Dynacat 2.0.0的發布，把這個概率往上抬了一截——開發者用三年時間，把Glance的架構拆碎重組，塞進了一個能自己盯著媒體庫變化的守護進程。

從"手動刷新"到"后臺盯梢"：動態更新的工程解法

Glance的老用戶都熟悉這個場景：下了新電影，打開面板，手動點刷新，等緩存重建。Dynacat 2.0.0把這個流程刪掉了——代之以一個后臺daemon（守護進程），按用戶設定的間隔自動輪詢媒體庫。

這個改動的技術代價不低。Glance的原始架構把更新機制寫死在渲染層，Dynacat的開發者選擇把整個數據流抽離出來，讓守護進程直接對接qBittorrent、Jellyfin、Emby、Plex這些平臺的API。結果是延遲從"分鐘級"壓到了"秒級"，代價是多跑一個常駐進程。

開發者留了后路：設置里可以關掉自動更新，切回手動模式。這個開關不是敷衍——有些用戶的媒體庫掛在NAS上，輪詢太頻繁會吵醒硬盤，他們寧愿自己控制節奏。

跨平臺集成的"縫合"邏輯

Dynacat 2.0.0的集成列表讀起來像一份 pirate（盜版）用戶的常用軟件清單：qBittorrent管下載，Jellyfin/Emby/Plex管播放。開發者沒有試圖取代其中任何一個，而是做了一個統一的讀取層。

具體實現上，每個平臺有獨立的適配器模塊，用各自的API拉取狀態，再統一到Dynacat的數據模型里。這意味著Jellyfin的"最近添加"和qBittorrent的"下載中"可以出現在同一個視圖里，不需要用戶切四個標簽頁。

這個設計的聰明之處在于不碰存儲層。Dynacat只讀元數據，不寫回任何平臺。既避開了權限糾紛，也讓風險可控——就算Dynacat崩了，用戶的媒體庫原封不動。

性能數字背后的取舍

官方沒有公布具體的基準測試數據，但從架構描述可以反推優化方向：Glance的每次刷新要重建整個前端狀態樹，Dynacat改成增量更新，只推送變化的部分。這個改動對大型媒體庫（數萬條目級別）的響應速度影響最明顯。

內存占用方面，守護進程的設計增加了常駐開銷，但減少了重復計算的浪費。開發者把這個權衡交給了用戶：輪詢間隔設得長，進程大部分時間休眠；設得短，實時性更好，但CPU和磁盤IO（輸入輸出）會上來。

開源分叉的生存算術

Dynacat的處境是典型的"技術領先、生態落后"。Glance有先發優勢，社區插件和主題積累了三四年；Dynacat從0開始攢貢獻者，API文檔寫得再清楚，也需要時間讓人進來寫擴展。

2.0.0版本的一個重要信號是模塊化框架的定型。開發者把核心功能拆成了可插拔的組件，第三方可以只接自己需要的部分。這個設計降低了參與門檻——你不用讀懂整個代碼庫，就能寫一個Plex的新適配器。

但分叉項目的詛咒始終存在。如果Glance的下個大版本抄走了動態更新，Dynacat的技術優勢會被快速稀釋。反過來，如果Glance的維護節奏繼續放緩，Dynacat有機會吃掉那批"愿意折騰但不想等"的用戶。

開發者在這個版本里埋了一個細節：默認配置保留了Glance的靜態刷新模式，用戶需要主動開啟守護進程。這個設計像是在說——我知道你們怕變，先讓你用著熟悉的，再慢慢誘你進新世界。

現在的問題是：有多少Glance用戶會為了自動更新，愿意多跑一個進程、多學一套配置？