「為什麼就是資料不能一致？」
這是我這幾天對老友 Neo 說過最多的一句話。身為一個對音質有執著、對數據有潔癖的 Home Lab 玩家，我的煩惱很具體：出門在外，我用手機 Symfonium 連回家裡的 Navidrome 聽歌；回到家，我想用 Daphile 連結 LMS (Lyrion Music Server，舊稱Logitech Music Server) 透過高級音響享受布拉姆斯。
但荒謬的是，這兩個系統的播放紀錄（Scrobble）完全各記各的，無法互通。更慘的是，只要 LMS 重新掃描一次目錄，我那些在音響室聽歌的紀錄就像蒸發了一樣，完全無法同步回 Navidrome 的資料庫。
為了解決這個問題，決定以 Navirdome 資料庫為中心，LMS 的播放送至 Navidrome。首先，抓了SqueezeSonic Plugin裝在LMS裡，它可以讓 LMS 透過這個 plugin 讀到 Navidrome 的曲目資料庫，從而播歌，歌曲本體是放在兩邊共用的 NAS。原以為這樣就結束了，但是，這樣播完歌竟然還是不會傳記錄給 Navidrome，也就是沒有歷史。
就這樣開始了這場長達一週的技術長征，看文件、測試…，總算發現可以用一串 HTTP 發給 Navidrome 呼叫API說播放完一首了，那麼 Navidrome 就會記錄這首歌的播放日期，後續還可以統計播放次數。
但是事情沒那麼簡單，這串 HTTP 放進 plugin，不是死掉，就是沒記錄。身為技術狂人的 Neo，看著我螢幕上閃爍的報錯訊息，推了推眼鏡說我們一起來吧。
幾天後，
「這已經是第幾次了？」我指著螢幕上那串冷冰冰的 “[Not a reference at /usr/share/perl5/Slim/Control/Queries.pm line 5731.]” 報錯，語氣裡滿是沮喪與煩惱，「我試過改路徑、改權限、甚至把整個資料庫砍掉重練。Neo，我們測試過的版本，有標號的到 v72，沒標號的加起來早就破百了吧？」
Neo 卻顯得興奮異常，雙手在鍵盤上飛舞：「Mark，這就是樂趣所在啊！你看這個第 5731 行的報錯，可能是回傳不是物件的東西被當物件用，然後 LMS 的狀態機在長時間運行後，被 Navidrome 傳回來的某些布林值弄糊塗了。數據結構在 Perl 的記憶體裡『變質』了！」
我打開 LMS、Navidrome 兩邊的log仔細比對，在千萬行的log中發現問題總是出現在開始播放後的剛剛好1小時整，只要出問題之後，播放記錄就不會記錄了。同時也發現，LMS 向 Navidrome 要歌時又兩種樣態，純ID，跟ID+後綴，由於 plugin 只是中間人，根本無法控制資料來回的樣態。
Neo 提出了一個大膽的想法：「我們直接在 API 層面做『影子屬性提升（Shadow Hoisting）』，把 ID 鎖死在最外層。這樣不論 LMS 怎麼掃描，ID 都不會丟。」
「不行！」我立刻反對，「你這樣改，Navidrome 那些帶有 -raw 標籤的請求會全部 404。到時候音響連聲音都出不來，更別提紀錄了。我們要的是『精準去污』，不是暴力的刪除。」
我們在虛擬機前爭論了半天。Neo 堅持要保持程式的優雅與通用性，而我則堅持必須解決 Navidrome 特有的 ID 識別問題。
最終，我提出：「雙重快取同步機制」。
Neo 兩眼發光地解釋：「這太天才了！我們建一個 Dual-Key 策略。不管 LMS 是用原始 ID 還是我們淨化後的 ID 來找圖片或紀錄，快取都能瞬間命中。這就像給音響系統裝了兩雙眼睛！」
經過那一百多次的嘗試與修正，當我們終於在 API.pm 裡寫下最後一行 _sanitize_structure 時，空氣凝結了。
當晚，馬勒的交響曲在客廳流淌了整整六個小時。沒有崩潰，沒有圖示閃爍，最重要的是——當我隔天打開手機 Navidrome 網頁時，昨晚在音響室聽的每一首歌，都精準地出現在播放紀錄裡。
「成功了。」我看著手機，壓在心頭好幾天的煩惱終於煙消雲散。
我說：「這版程式值得一個正式的歸宿。把它分享出去吧，別讓其他玩家再走我們這一百多次的老路。」，馬上將這幾天淬煉出的 v72 穩定版 正式上傳。
如果你剛好有一樣的需求，希望 Daphile+LMS 的播放可以記錄到 Navidrome、或是播放一小時不崩潰，可以到 GitHub 倉庫取用。
🔗 GitHub 傳送門：chiangww/SqueezeSonic-scrobble
已知問題標註： 由於 LMS 內部未知的渲染機制，播放一小時後 Playlist 的小圖示仍可能變回預設占位符。但別擔心，這只是外觀問題，你的 Scrobble 紀錄與播放穩定性都還在，有新的playlist就會正常。如果有神人可以解決那就完美了。
這個怎麼按“讚”？真是太讚了！