ネットワーク共有を再マウントした後、変更されていないライブラリのメディアサーバーによる再スキャンを止める方法

メディアサーバーでは、ストレージが一時的に消失したり、スキャナーが変更ありと判断するファイルシステムビューで復帰したりすると、内容が変わっていないライブラリをネットワーク共有の再マウント後に再スキャンすることがあります。

これは通常の起動時スキャンとは異なる、より限定的な現象です。安全であればメディアサーバーのプロセスを稼働させたまま、同じ SMB または NFS 共有を意図的に再マウントし、移行の前・最中・後にサーバーが認識している状態を記録してください。重要なのは、メディアファイル自体が変わっていないにもかかわらず、ライブラリのパスが空になったのか、アクセス不能になったのか、新たにマウントされたのか、それとも別の変更シグナルが生成されたのかという境目です。

再スキャンが共有の再マウント後に発生することを確認する

関係のないスケジュールスキャンを一時的に無効にし、メンテナンス時間帯にテスト用共有を1つアンマウントして再マウントしながら、ライブラリのスキャンログを記録します。共有が消失しない通常のサーバー再起動と、スキャンのトリガーを比較してください。

Jellyfin は、リモートメディアが存在しない状態でスケジュールされたメンテナンスが実行されると、利用できないストレージによって項目が削除される可能性があると警告しています。

再スキャンが共有の切り替え後にのみ開始される場合は、ストレージの可視性とスキャナーイベントに絞って診断してください。マウントの変更がないのにサーバーが再スキャンする場合は、スケジュールタスクまたは永続化されたデータベース状態を改めて確認します。

再マウント中もライブラリのパスを維持する

リモート共有の再接続前・最中・後に、ホストのマウントポイントを確認します。同じパス名にある空の通常ディレクトリは、明示的なマウント失敗より危険な場合があります。メディアサーバーが、そのディレクトリを有効だが空のライブラリとして解釈する可能性があるためです。

Jellyfin の最新のトラブルシューティングガイドでは、マウント失敗によってライブラリが空になり、大規模な修正スキャンが開始される仕組みを説明しています。

空のフォールバックディレクトリを公開するのではなく、明確に失敗するマウント方式を優先してください。メディアサーバーのコンテナまたはサービスに再びパスへのアクセスを許可する前に、ホストから見える状態を検証します。

ネットワークファイルシステムとローカル変更通知を切り分ける

サーバーがファイルシステムウォッチャー、定期スキャン、アプリケーションコールバック、またはサードパーティ製のメディアマネージャーのどれに依存しているかを確認します。リモートマウントでは、直接接続されたファイルシステムと同じローカル変更通知が常に配信されるとは限りません。

Plex は、ネットワーク共有には変更トリガーがなく、そのため定期スキャンまたは明示的なスキャンが必要になる場合があると説明しています。

回避策として、頻繁な定期スキャンと広範な外部更新フックを同時に有効にしないでください。信頼できる通知方法を1つ選び、再マウントによって複数のライブラリ全体スキャンが重複して発生しないようにします。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

コンテナが再接続する前にストレージを準備する

メディアサーバーが Docker 上で動作している場合は、リモートマウントの準備完了時刻と、コンテナの起動または再起動時刻を比較します。コンテナがホストのマウントポイントを、まだ空のローカルディレクトリである段階でバインドし、その後に NAS がその下に現れることがあります。

Linux のホームサーバー向けガイドでは、リモートストレージに依存するアプリケーションでは、Docker より先にストレージをマウントする必要があると説明しています。

長い固定スリープではなく、上限時間付きのマウント依存関係または準備完了チェックを使用してください。メディアサーバーは、実際のライブラリが利用可能な状態で起動するか、空のプレースホルダーをインデックスできないことが明確に分かる形で失敗する必要があります。

Inotify がすべての NAS の変更を通知すると期待しない

Linux では、自動メディア検出がローカルファイルシステムイベントを中心に構築されていることがよくあります。NAS 上で直接ファイルを追加したときにメディアサーバーのホストでウォッチャーイベントが生成されるか、また再マウントによってより広範なディレクトリ変更シグナルが発生するかを比較してください。

ホームサーバー向けの自動マウントガイドでは、inotify がネットワークファイルシステムの変更を見逃すことを説明し、適切な場合にはアプリケーションから明示的に通知することを推奨しています。

ウォッチャーの動作が信頼できない場合は、サーバーに変更されていないライブラリ全体を再検出させるのではなく、メディアマネージャーまたはサーバー API を使用して、新しく追加されたコンテンツを対象とするスキャンをリクエストしてください。

全体再スキャンなしで、制御した再マウントを1回確認する

マウントの可視性、起動順序、またはスキャンのトリガーを修正したら、ライブラリデータベース、項目数、スキャンログを監視しながら共有を2回再マウントします。その後、正当な新規メディアが引き続き検出されることを確認するため、テストファイルを1つ追加してください。

ホームメディアに関する比較記事では、NAS のプロトコルによってマウントの動作が変わるのであり、メディアサーバーがリモートファイルシステムを直接所有するわけではないと説明しています。

再マウント後も変更されていないライブラリが全体再スキャンなしで維持され、選択した更新方法によって新しいファイルが引き続き表示されれば、修正は完了です。症状がホストの再起動後にのみ発生する場合は、Jellyfin の再起動時再スキャンに関する関連 ZimaSpace 記事が適切な分岐先です。