Immichでジョブやインポートの重複を防ぐ方法

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

How to Prevent Duplicate Jobs or Imports in Immich - Zima Store Online

Immichのジョブやインポートの重複を防ぐには、まず2つの異なる症状を切り分けます。同じバックグラウンド処理が再び実行されているのか、それとも同じ写真が複数のアセットになっているのかを確認してください。そのうえで、削除する前に、どのクライアント、インポーター、ライブラリスキャン、パス変更、またはリトライによって2つ目のイベントが発生したのかを特定します。

最も安全な設計は、各アセット群に1つの正規の取り込み経路を割り当てることです。過去のクラウドアーカイブ、外部ライブラリ、現在使用中のスマートフォンバックアップはすべて有効ですが、同じファイルを複数の場所で管理すると、重複レコードや再アップロードループが発生し、インポート後のクリーンアップだけでは確実に解決できない場合があります。

繰り返される処理か、重複アセットかを確認する

ジョブが繰り返されている場合は、キュー名、アセットID、開始時刻、完了または失敗の状態、新しいジョブに先行したイベントを記録します。メタデータ処理の後に正当に作成された後続ジョブと、同じ失敗ジョブが延々とリトライされている状態は異なります。どのパターンなのかを把握するまで、すべてのキューをクリアしないでください。

重複アセットについては、ソースライブラリ、元のパス、利用可能な場合はチェックサムの挙動、デバイスのバックアップ状態、撮影時刻、ファイルサイズを比較します。同じように見える写真でも、クラウドからのエクスポート、メタデータの編集、トランスコード、またはパスベースの外部ライブラリ処理によって異なるファイルになることがあります。一方、バイト単位で同一のファイルが異なるImmichライブラリソースに存在する場合もあります。

通常のアップロードでチェックサムエラーや一意制約エラーが繰り返し発生し始めた場合は、インポート元の問題だと判断する前に、データベースを保全し、マイグレーションやスキーマの状態を確認してください。2種類の正当なソース間にある重複アセットと、データベース制約の失敗は別の分岐であり、同じクリーンアップを適用すべきではありません。

スマートフォンのバックアップ状態とモバイルスケジュールに関するZimaSpaceガイドは、モバイルクライアントがバックアップの必要なファイルを独自に判断しているため役立ちます。クライアントの状態を無視したサーバー側のクリーンアップを行うと、次回のスマートフォンセッションでファイルが再送信される可能性があります。

既存の写真群ごとに1つの正規取り込み経路を使用する

継続的なスマートフォンバックアップを有効にする前に、古い写真をどのようにImmichへ取り込むかを決めます。たとえば、過去のアーカイブを一度インポートして検証し、その後はスマートフォンから新しく撮影した写真だけを追加します。同じ過去のファイルを外部ライブラリとしてマウントし、通常のアップロードライブラリからもアップロードしている場合、グローバルな重複排除によって2つのソースが自動的に統合されるとは考えないでください。

Immichのソース横断の重複に関する報告では、外部ライブラリとアップロードライブラリに由来する同一内容が共存する事例が記録されています。これはプロジェクトの動作上の境界として扱ってください。どのソースが所有するかが重要であり、後から重複削除ツールが希望するコピーを推測してくれると期待するより、事前に重複を防ぐほうが確実です。

スマートフォンがまだバックアップ対象として認識している間に、Immichが内部的にアップロードしたファイルを、Immichに知らせず外部ライブラリへ移動することは避けてください。ストレージ構成を変更する必要がある場合は、バックアップを取り、少数のテスト対象で文書化された手順を使って移行します。その後、古いコピーを削除する前に、モバイルアプリとサーバーの認識が一致していることを確認してください。

インポートを拡大する前にリトライとクライアント状態を制御する

大規模な手動インポートでは、ステージング用のマニフェストを使用します。実用上可能な範囲で、ソースパス、ファイル数、合計バイト数、安定したチェックサムまたはインポーターの結果を記録してください。インポートが中断された場合は、最初のジョブの状態が不明なまま同じソースに対して別の独立したインポーターを起動するのではなく、同じツールと保存先を使って再開します。

最近のImmichの繰り返しアップロードに関する報告では、サーバーにすでに存在するアセットをモバイルクライアントが継続的にリトライし、サーバー側で一意制約エラーが発生していました。これは、特定のバージョンにおいてクライアントのバックアップ状態がループの原因になり得ることを示す証拠として扱い、モバイルアプリ全般の普遍的な挙動だと一般化しないでください。パスの変更は別のリスクです。大規模なインポート中は、コンテナから見える外部ライブラリのパスを安定させてください。ストレージの移動が必要な場合は、まず少数の対象で移行します。パス変更後にのみ2つ目のコピーが現れる場合は、スマートフォンのバックアップ状態をリセットするのではなく、パスの識別情報に関する分岐を確認してください。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

中断、リトライ、本当に新しいアセットをテストする

通常の写真、動画、編集済み画像、保存先のパスにすでに存在するファイルを少なくとも1つ含む、代表性のある少数の対象群を作成します。1回インポートしてアセット数とIDを記録し、その後、本番で使用する予定のワークフローに従って、2回目の試行または再スキャンを意図的に中断してテストします。

成功の条件は、同じ元オブジェクトに対して説明のつかない2つ目のアセットが作成されないこと、リトライがキューを恒久的に増加させることなく収束すること、そして本当に新しい写真が正常にインポートされることです。さらに、テスト後にモバイルクライアントを再度開き、バックアップ状態がサーバーと暗黙に食い違わないようにしてください。

アップロードと外部ライブラリのソース間でのみ重複が再発する場合は、何度も結合を繰り返すのではなく、所有権の境界を設計し直します。同じアセットIDで失敗ジョブが延々と続く場合は、そのジョブとファイルを分離してください。エスカレーション時には、ソースの種類、パス、関連するハッシュ、バージョン、クライアントのバックアップ状態、再現可能な最小の対象群を提示します。