新しくインポートしたImmichの写真が検索可能になるまで時間がかかるのはなぜですか？

エヴァ・ウォン

IceWhale author

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

Why Are Newly Imported Immich Photos Slow to Become Searchable? - Zima Store Online

新しい写真は通常、バックグラウンド処理が追いつくと検索可能になりますが、ジョブの停滞や検索フィルターによって、同様に結果が表示されない症状が生じることがあります。

スマートフォンから家族用サーバーへの旅行アルバムのアップロードは完了したものの、「ビーチ」で検索すると古い写真しか表示されません。表示されない結果は、分析を待っている、処理の早い段階で失敗している、または現在のクエリから除外されている可能性があります。何も返さなかった一度の検索だけで、インポート全体を判断するよりも、これらの状態を切り分けることが重要です。

アップロード済みの写真でも検索を待っている場合がある

アップロードが受け付けられたこと、タイムラインのタイルが表示されること、セマンティック検索のレコードが完成していることは、それぞれ異なる段階です。バックグラウンド処理により、サーバーはすべての分析ステップを同期的に完了しなくてもリクエストを受け付けられます。この分離によって柔軟性は高まりますが、アップロード件数だけでは、すべての新しい画像が自然言語クエリに一致するようになる時期を家族に伝えることはできません。

ジョブキューの分離によって、この違いを確認できます。Immich向けのキュー可視化ツールを作成した開発者は、処理速度のグラフとともに、保留中、実行中、完了済みの処理を表示します。重要なのは追加ツールそのものではありません。複数の処理がそれぞれ独立して進むため、転送が落ち着いた時間があっても、ライブラリ全体の処理が完了したとは限らないという点です。

例として、処理対象となる保留中のジョブが12,000件あり、毎分100件の一定ペースで処理されるなら、新たな到着が止まった後でも約120分かかります。毎分80件が追加される場合、純減は毎分20件にすぎません。実際のジョブごとにコストは異なるため、この計算はバックログの挙動を説明するものであり、Immichの完了時刻を予測するものではありません。

3つの異なる状態が同じ遅延に見えることがある

次の3つの状態を区別してください。キューが意図的に待機している、キューがゆっくり進んでいる、必要な出力が生成される前にジョブが繰り返し失敗している、の3つです。1つ目は実行する権限がない状態、2つ目は到着率に対して処理能力が不足している状態、3つ目は特定のエラーによって時間を失っている状態です。大量の保留件数は、これら3つすべてで発生し得ます。

報告されているメタデータのタイムアウトは、一般的なハードウェアの限界を証明するものではなく、3つ目の状態を示す例です。報告者は、NFSベースのライブラリにある動画で120秒後の失敗を確認しましたが、同じファイルをホスト側で抽出すると高速でした。この対比からは処理経路の不一致が分かりますが、すべてのNASストレージや大規模インポートが同じように動作することを示すものではありません。

保留中の処理が減り、失敗件数が安定しているなら、遅延したカバレッジはバックログが解消中であることと整合します。減っていない場合は、システムが過負荷だと判断する前に、処理が一時停止しているのか、アクティブなエラーが発生しているのかを区別してください。これは分類の境界を示すものであり、キューの消去、すべてのサービスの再起動、家族のコレクション全体の再実行を推奨するものではありません。

検索範囲がインデックス未完了のように見えることがある

処理状態を確認したら、アカウント、アルバムの範囲、日付フィルター、クエリを固定してください。同じサーバー上でも、別の家族用アカウントから検索すると、対象となる結果が変わることがあります。また、セマンティッククエリは類似度の順位付けを行うものであり、完全な一覧を保証するものではありません。そのため、視覚的に一致する結果が1つ見つからないだけで、インデックス作成が未完了だと判断することはできません。

HEICのプレビュー欠落は、別の曖昧さをもたらします。元の画像は存在していても、表示用の派生データが利用できない場合があります。形式、デコーダーの挙動、特定の画像プロファイルがこの経路に影響することがあります。タイルが欠落していることと検索ベクトルが欠落していることは、同じ写真で両方の問題がユーザーに現れる場合でも、異なる観測結果です。

残りのコホートの処理が完了した後も、同じ小さな一部だけが一貫して失敗するなら、通常のバックログという説明は当てはまりません。逆に、既知のアセットを正常に検索できる一方でセマンティックな一致度が低いなら、クエリの関連性やモデルの挙動が原因である可能性があります。検索語の最初の表現で取得できなかったというだけで、元の画像を再インポートしないでください。

-15% OFF

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

Single board computer zimaboard2

小規模なコホートで待機と停滞を見分ける

日付を特定でき、内容にもばらつきがある新規インポート済みアセットを少数選び、すでに正常に動作することが分かっている古いアセットのセットも用意します。各元画像が受け付けられた時刻、プレビューが開いた時刻、関連するジョブが完了した時刻、固定したクエリで取得できるかどうかを記録します。モデルを変更したり、ライブラリ全体の再処理ジョブを開始したりせず、記録した間隔で繰り返し確認してください。

インポートのスケジュールによっては、バックグラウンド処理が意図的に後回しにされることがあります。immich-goのリリースでは、メタデータ更新の同時実行による競合を避けるため、アップロード中にジョブを一時停止する機能が導入されました。これは特定の一括インポート方針を示す証拠であり、ネイティブモバイルアプリも同じ方法でジョブを一時停止することの証明ではありません。コホートを作成したインポーターとバージョンを記録してください。

完了件数が増え、古い結果が安定しているなら追いつき中と解釈します。同じファイルで失敗が繰り返されるなら処理上の問題、アカウントごとに結果が異なるなら範囲の問題と考えます。進行が止まった場合は、これらの観測結果とバージョンの詳細を添えてエスカレーションしてください。適切な診断では、証拠を削除したり複数の変数を同時に変更したりせず、失敗している段階を絞り込みます。