サーバーがマウントされたパスをたどれない、異なるパスを認識している、または識別時にファイルを拒否すると、メディアスキャンで映画が見つからないことがあります。
ホームNASでは、「共有がマウントされている」とは、ホストのシェルからディレクトリが見えるという意味にすぎない場合があります。メディアサーバープロセスがDocker内部で動作していたり、別のバインドパスを使用していたり、異なるUIDで実行されていたり、リモート共有の切断後に残った空のローカルマウントポイントをスキャンしていたりする可能性があります。パス、権限、命名、パーサーの問題では、何度も全体スキャンを実行しても修復できません。ストレージからアプリケーションまで、見つからない映画を1本ずつ診断してください。
現在マウントされている共有に映画が存在することを確認する
ホストからライブラリの正確なソースパスを確認し、見つからない映画を完全なファイル名で1本リストアップします。マウントポイントのディレクトリが存在するというだけで判断せず、ファイルシステムの種類、マウント元、マウントオプション、空き容量、既知のファイル数を確認してください。
切断されたネットワーク共有は、同じマウントポイントに通常の空のディレクトリを残すことがあります。その結果、メディアが見つからなくてもスキャンが正常に完了する場合があります。Jellyfinの報告では、対象パスの項目数がゼロとして解決されたにもかかわらず、スキャンが成功したように表示されました。
見つからないファイルの一部を読み込み、その親ディレクトリを一覧表示します。共有が存在しない場合は、スキャン前にマウントを復元し、リモートファイルシステムが利用可能になってからメディアサービスが起動するよう設定してください。空のローカルマウントポイントを2つ目のライブラリパスとして追加しないでください。
メディアサーバーコンテナ内からパスを確認する
実行中のコンテナに入り、ライブラリで設定されている正確なパスを確認します。ホストでは /mnt/media/movies を使用していても、コンテナからは /media/movies として見える場合があります。アプリケーションに指定するのはコンテナ側のパスだけです。
古い項目は再生できるのに新しいメディアが見えない場合、実行中のコンテナが現在のホストパスを認識していないか、古いマウント内容を参照している可能性があります。Jellyfinの事例では、繰り返しスキャンを実行しても新しいメディアが表示されませんでした。
コンテナのマウント定義と、ランタイムが表示する実際のマウントを比較します。バインド元が親ディレクトリや古いパスではなく、実際にマウントされた共有であることを確認してください。永続構成とデータベースのマウントが変更されていないことを確認してから、コンテナを再作成します。
実際のサービスユーザーでディレクトリをたどれるかテストする
メディアサーバーのUIDとGIDを使用して、ライブラリのルートから映画ファイルまでの各ディレクトリを一覧表示します。ファイルを読み取れるだけでは不十分です。プロセスがパスをたどるには、すべての親ディレクトリに対する実行権限も必要です。
Jellyfinのライブラリ表示に関する問題では、読み取り権限とディレクトリの実行権限の不足が、項目が表示されない直接の原因として特定されています。重要なのはディレクトリをたどる権限であり、管理者アカウントから共有を参照できるかどうかではありません。
サービスにメディアの読み取り専用アクセスを与えるため、所有者、グループ、ACLのうち最小限のルールだけを修正します。共有にはSMB経由でアクセスできるのにコンテナ内ではできない場合は、ZimaSpaceのファイル移動後の権限ガイドに記載された関連手順を参照してください。
見つからない映画と検出された映画を1本ずつ比較する
同じマウント済み共有内から、ライブラリが検出する映画のフォルダーと、検出しない映画のフォルダーを1つずつ選びます。ファイル名、拡張子、フォルダーの深さ、大文字と小文字、特殊文字、ファイルサイズ、シンボリックリンクの使用、権限、タイムスタンプ、ファイルが完全かどうかを比較してください。
スキャナーの失敗は、共有全体ではなく特定の項目に限られる場合があります。Jellyfinの報告事例では、検出されなかった映画が別のフォルダーへ移動した後にのみ表示されました。このため、全体の再スキャンを繰り返すより、検出された項目と見つからない項目を管理された条件で比較する方が有効です。
テスト用にコピーした項目だけを、Movies/Movie Name (Year)/Movie Name (Year).mkv のような単純な構成へ名前変更または移動します。コピーが表示される場合は、ライブラリ全体を変更する前に、元のフォルダーの命名、非表示マーカー、権限、ファイルシステムの動作を調べてください。
最初に見つからなくなったパスのスキャナーログを確認する
対象ディレクトリにスキャナーが入った時点からログを追跡し、対象を絞ったスキャンを開始します。アクセス拒否、ディレクトリが見つからない、I/Oエラー、未対応ファイル、プローブ失敗、データベース制約、メタデータプロバイダーのエラー、スキャンのキャンセルを検索してください。
パスレベルの例外が発生すると、全体スキャンが停止したり、一部の処理をスキップしたりすることがありますが、ユーザーインターフェースには不完全なライブラリしか表示されない場合があります。Jellyfinでは、ディレクトリが見つからない例外の影響を受けたスキャンが報告されています。そのため、最終的な進行状況表示よりも、最初に発生したエラーの方が重要です。
繰り返し発生する最初のエラーを修正し、可能な限り小さい範囲でスキャンを再実行します。パスの可視性と権限を確認する前に、ライブラリデータベース、メタデータ、キャッシュを削除しないでください。破壊的なリセットを行うと、マウントされた共有を修復できないまま、診断に必要な証拠だけが失われる可能性があります。
管理されたインポートと再起動で修正を確認する
同じ共有に、わかりやすい名前のテスト用映画を1本追加し、対象ライブラリをスキャンします。正しいパスとメタデータで1回だけ表示されることを確認してください。その後、コンテナを再起動し、ホストを再起動します。
再起動後、メディアサービスより先にリモート共有がマウントされること、コンテナから内容のあるパスが見えること、サービスユーザーがそのパスをたどれること、手動で権限を変更しなくてもスキャナーが新しく追加したテストファイルを検出することを確認します。
実際に見つからなかった映画が意図したマウント先から表示され、空の代替ディレクトリがスキャンされず、その結果が再マウント、コンテナの再作成、ホストの再起動後も維持されて初めて、修復は完了です。元のライブラリパスが安定していることを確認したら、テスト用コピーを削除してください。
サポートとヒント
もっと読む

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

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

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

