科技 · 實用指南
Immich 下載 Live Photo 後只剩靜態圖：改識別碼前先檢查什麼
遠端能播放、檔案識別碼一致、成功存下一張照片，分別證明不同的事。先檢查兩份原始資源與「照片」裡的還原結果，再判斷備份是否真的還原。
如果 Live Photo（原況照片）在 Immich 中能播放動態，但新存入 Apple「照片」的項目只是靜態圖，就還不能確認原況照片已還原。保留原始檔，先確認靜態照片和配套影片都在，檢查實際檔案類型及相關識別碼，再到「照片」中驗證還原出的項目。修改 UUID 不應是第一步。
這些檢查必須分開，有明確的程式碼依據：我們查看的 Immich v3.2.1 和 v3.3.5 行動版儲存服務中，某個 Photos 錯誤分支會嘗試只儲存靜態圖，並以回傳的靜態資源是否非空判定成功。這證明原始碼存在降級儲存路徑，並不證明你的問題由此引起，也不表示每一種完成提示都來自該回傳值。
伺服器關聯、兩份檔案和還原出的原況照片，是三種證據
Immich 可以將照片與影片關聯，並在自己的檢視器中播放動態。這回答的是伺服器上的關聯問題；下載後有兩份檔案，回答的是資源是否保留下來；新項目能否在 Apple「照片」中作為原況照片播放，才回答你關心的還原問題。不能把前一項觀察直接當成後一項的證明。
Apple 文件說明，影片的內容識別碼會與對應靜態照片 Exif MakerNote 中的中繼資料關聯。Immich 自己的連結則是資料庫關係。因此，在 Immich 中重新關聯兩項資源，本身不能證明檔案內嵌的 Apple 中繼資料已經改變，更不能證明「照片」會接受這對檔案。
保留原始資源，並記錄發生問題的下載方式
從自己的封存資料或原始檔下載中取得靜態照片及其配套影片，只在副本上操作，並將兩者放在獨立資料夾。如果匯出只得到靜態圖，應先找回對應的原始影片；螢幕截圖、預覽圖或將檔案改名為 .MOV，都不能補回缺失的動態內容。不要直接修改 Immich 管理的儲存目錄來試驗修復。
記錄 Immich 伺服器版本、行動 App 版本、iOS 版本，以及結果來自行動版「儲存」、網頁下載還是其他匯出方式。也要註明來源是 Apple 原況照片還是 Android 動態相片。本指南檢查的是 Apple 原況照片的還原問題，不保證跨平台動態相片轉換成功。
只讀取檔案類型與識別碼群組，不寫入中繼資料
安裝 ExifTool 後，先執行 `exiftool -ver`，再執行 `exiftool -a -G1 -s -FileType -ContentIdentifier "photo.JPG" "photo.MOV"`，將引號中的兩個路徑替換為副本路徑。這些選項只讀取中繼資料。保留輸出中的檔案界線與群組名稱；檔名以 .MOV 結尾，不能取代實際檔案類型檢查。
在我們檢查的 iPhone 樣本中，靜態照片顯示 [Apple] ContentIdentifier，影片顯示 [Keys] ContentIdentifier。比較這兩個值，不要因為外觀相似，就拿 ImageUniqueID、檔名中的 UUID 或無關的 XMP 值代替。如果某個群組缺少、多項數值衝突，或工具無法讀取檔案，應如實記錄不確定性，不要判定配對有效。
兩組真實故障樣本說明，單一中繼資料配方並不足夠
我們使用 ExifTool 13.59，只讀檢查了 Immich 問題 14066 與 15805 所附的公開 JPEG/MOV 壓縮檔。兩組都含有一張 JPEG 與一個 MOV；第一組的 Apple/Keys 內容識別碼不同，第二組相同。讀取前後的 SHA-256 檢查確認，四個檔案的內容都沒有改變。
這些結果只說明所提供檔案的中繼資料情況，不能診斷原先的故障。問題 14066 也包含缺少工作紀錄的錯誤；問題 15805 則被後續修正影片下載 URL 的修補明確列為修復對象。我們沒有執行 iOS 或 macOS 還原測試，而且伺服器匯出的一對檔案正確，也不能證明早期行動版實際下載了哪些位元組。
依照已有證據決定下一步
如果影片缺少、無法讀取，或實際又是一張圖片，應先取回正確的原始資源，再考慮配對。如果相關識別碼缺少或不同，應回到來源封存資料及匯出紀錄，確認哪張照片與哪個影片原本屬於同一組。相同的主檔名或接近的拍攝時間只是線索，不能據此任意選取檔案並覆寫識別碼。
如果相關識別碼已經相同，就不要繼續把替換 UUID 當成通用修復。保留這對檔案，改為檢查資源傳遞與寫入「照片」的路徑。現有修復工具可以在檔案間複製識別碼，但不能據此認證影片、其餘中繼資料或 Apple 的接受結果。識別碼一致卻還原失敗，代表需要更好的診斷證據，而不是反覆寫入同一個值。
分開看待歷史用戶端修復與靜態圖降級儲存
這裡有兩個已存在的用戶端修復值得區分：PR22708 修正了影片請求誤用靜態照片 URL 的問題；PR29952 修正了已完成原況照片下載工作的分組與回呼互動。這說明資源傳遞故障可以獨立於原始檔的識別碼問題存在。任何一個修補都不能證明後來所有「只剩靜態圖」報告的原因。
所查 v3.2.1/v3.3.5 儲存程式碼仍會捕捉錯誤碼以 PHPhotosErrorDomain 開頭的例外，嘗試呼叫 saveImageWithFile，並回傳靜態圖儲存是否得到資源。我們沒有將這個布林值追蹤到每一種介面狀態。可靠結論應限定為：傳輸進度與已儲存的靜態圖，都不足以證明完整原況照片已還原。先記錄版本，再於受支援的更新後用保留好原件的單一樣本複測，不要盲目套用舊修補。
在 Apple「照片」中驗證這次新還原的項目
檢查這次還原建立的項目，不要誤看圖庫裡原本就正常的舊副本。Apple 目前的 iPhone 指引為「照片」→「選集」→「媒體類型」→「原況照片」；開啟項目後按住螢幕播放。如果「照片」仍提供原況控制項，應先確認原況效果是否被關閉，再判斷動態內容是否缺少。
一個能單獨播放的 MOV 是值得保留的資源，但不能證明「照片」已將它還原為一項原況照片。目標裝置與預期流程通過驗證前，繼續保存原始檔。不要為了建立乾淨的測試環境而刪掉唯一正常的副本；可以使用原始資源已另行保存的現有失敗樣本，或在條件允許時使用獨立測試目的地。
記錄還原結果，避免誇大成功範圍
對測試樣本，保留版本、匯出方式、兩份檔案的類型、相關識別碼是否一致，以及「照片」的實際播放結果。有效的支援報告可以明確區分「原始影片缺少」、「兩份資源都保留，但還原尚未確認」與「已在這台裝置上還原並播放」。若出現錯誤，應附上準確錯誤內容；沒有報錯並不能自動證明儲存成了原況照片。
這套流程協助縮小下一步的判斷範圍，不能找回已經不存在的影片影格，也不能認證所有識別碼一致的檔案對。實際目標是得到誠實的還原結論，並保住來源資源。僅憑伺服器能播放動態，不應丟棄仍需還原的原況照片剩餘副本。
