人物認識では、共有によってアセットが表示可能になっていても、Peopleインデックスが使用する所有範囲または処理対象範囲に含まれていない場合、共有アルバムの写真が無視されることがあります。
重要なのは、単純に共有かプライベートかを区別することではありません。所有している写真と似た共有写真を比較し、両方で顔処理ジョブが実行されたかを確認して、それぞれのアセットをどのアカウントまたはライブラリが所有しているかを特定します。影響を受けた写真が、アプリケーションのインデックス対象として設計された範囲に属していることを確認してから、顔データを再構築してください。
アルバムの表示範囲と顔インデックスの表示範囲を分けて確認する
影響を受けた共有写真を1枚開き、閲覧者がそのアセットを見られることを確認します。次に、Peopleまたは顔検索の画面に同じ写真が表示されるかを確認してください。これらは、別々の権限と処理に関する問題として扱います。
共有Immichアルバムのようなワークフローからも分かるように、アセットを別のユーザーに表示可能にしても、派生するすべての整理機能まで引き継がれるとは限りません。
写真は表示されるのにPeopleにまったく表示されない場合は、アルバム共有だけのトラブルシューティングを続けないでください。次のテストでは、アセットを所有しているアカウントと、顔処理パイプラインがインデックスするアセットを特定します。
所有している対照写真と比較する
見た目がよく似た写真を2枚用意します。1枚はPeopleビューが正常に機能するアカウントがアップロードした写真、もう1枚は共有アルバム経由でのみ表示される写真にします。両方に明瞭な顔が含まれ、同じ時期に追加されたことを確認してください。
セルフホスト型のImmich環境には、Immichの処理アーキテクチャ、ストレージ、ジョブ、クライアントの各レイヤーがあります。そのため、対照テストでは画質を一定に保ち、所有者またはライブラリの範囲だけを変更します。
所有しているアセットだけに顔メタデータが付与される場合、症状の原因は画質ではなく対象範囲です。所有権の境界を理解する前に、認識のしきい値を変更しないでください。
顔処理ジョブが実際に実行されたか確認する
影響を受けたレコードについて、顔検出と顔認識のジョブキューおよびアセットメタデータを確認します。所有している対照写真と、タイムスタンプやジョブの完了状況を比較してください。
独立したImmichの運用情報では、Immichの機械学習ジョブはバックグラウンド処理として説明されています。つまり、すべての機械学習による派生データの生成が完了する前に、アップロードまたは共有されたアセットが表示されることがあります。
共有アセットでジョブが一度も実行されていない場合、再処理を行う意味があるのは、そのアセットが処理対象として適格であることを確認した後です。対象外の範囲に対して何度も再試行すると、計算リソースを浪費し、本当の境界を見えにくくします。
目的に合った共有モデルを選ぶ
家庭内で必要なのが共有閲覧だけなのか、それともすべての写真を横断した統合Peopleインデックスなのかを決めます。これは異なる製品上の動作であり、共有所有権、パートナー形式の共有、または共通の管理ライブラリが必要になる場合があります。
実用的な共有フォトライブラリの設計を確認すると、共有ライブラリの整理方法によって、共通化されるものと個々のユーザーに紐付いたままになるものがどのように変わるかが分かります。
顔認識を強制するためだけに、すべての写真を別のユーザーのライブラリへコピーしないでください。重複ストレージや削除時の動作を許容できる場合を除き、アプリケーションがサポートする共有モデルを優先します。
対象範囲を正しくしてから再処理する
アセットが顔処理を受けるべき範囲に属したら、サポートされている最小単位の顔検出または顔認識ジョブをテスト用の一部に対して実行し、結果を比較します。
関連するZimaSpaceのImmich家族向けフォトライブラリガイドでは、変更をバックアップに対応したフォトライブラリのワークフロー内に収めています。そのため、オリジナルを危険にさらすことなく、派生した顔データを再構築できます。
通常の処理後、処理対象になった新しい共有写真が期待どおりPeopleビューに追加されれば、修正は成功です。処理対象として適格な所有写真の対照データでも失敗する場合は、モデル、ワーカー、またはリソースの障害を調査してください。
サポートとヒント
もっと読む

Plexは別のDockerコンテナとGPUを共有できますか?
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。

Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。

Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。

