再起動後にJellyfinの再生がうまくいかなくなるのはなぜですか？

再起動前はJellyfinが正常に動作していたのに、その後再生できなくなった場合は、ライブラリを変更する前に、起動時に復旧すべき依存関係を確認してください。

再起動によって、マウントのタイミング、コンテナのデバイスマッピング、権限、DNS、サービスが利用可能になる順序が変わることがあります。Jellyfinのプロセスが正常でも、メディアパスやGPUが使用可能とは限りません。起動後の環境を正常動作時の基準と比較し、最初に欠落した依存関係を修復してください。

メディアのマウントが本当に完了しているか確認する

通常NASやディスクが割り当てられるディレクトリは、実際のストレージがマウントされていなくても存在することがあります。その場合、Jellyfinは空のローカルパスを認識し、明確なマウントエラーではなくメディアが見つからないという形で報告することがあります。

サービス起動前のマウント確認により、アプリケーションが空のマウントポイントへ書き込んだり、そこをスキャンしたりするのを防げます。

findmntまたはプラットフォームに相当するコマンドでファイルシステムの識別情報を確認し、Jellyfinサービスのユーザーで既知のメディアファイルを読み取ってください。意図したストレージが利用可能になるまで、再スキャンは実行しないでください。

ランタイム復旧後にアプリデータの所有権を確認する

コンテナの再作成やホストの変更によって、永続構成へアクセスする数値ユーザーIDが変わることがあります。読み取り権限だけでは不十分です。Jellyfinにはデータベースや構成状態を更新する権限も必要です。

バインドマウント全体でUIDとGIDのマッピングがファイルシステムの所有権と一致していると、UIDとGIDのマッピングを利用するコンテナサービスは安定して動作します。

サービスのIDでアプリデータの親ディレクトリ内に一時ファイルを作成し、削除するテストを実行してください。永続アプリデータパスは、再帰的な所有権修正を行わなくてもランタイムの置き換え後に維持される必要があります。

ハードウェアデバイスが再び認識されているか確認する

再起動前はiGPUを使用していたトランスコードが、/dev/driや別のアクセラレーターのマッピングが欠落すると、CPU処理へフォールバックしたり失敗したりすることがあります。ダイレクトプレイは引き続き動作する場合があるため、障害がメディア固有の問題に見えることがあります。

デバイスマッピングに失敗すると、同じ再生処理がハードウェア処理からソフトウェア処理へ移行することがあります。Jellyfinトランスコードベンチマークでは、ハードウェアアクセラレーションを使用する経路とフィルタ処理を行う経路で、CPUとGPUの負荷がどれほど大きく変化するかを確認できます。

既知のハードウェアトランスコードテストを1つ再生し、実行中のプロセスとデバイスマッピングを確認してください。画質を下げたりコーデックを変更したりする前に、ランタイムからデバイスへアクセスできる状態を修復してください。

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

ローカル再生が動作してからネットワーク経路を再テストする

リモートDNS、VPN、プロキシサービスがJellyfinより後に起動すると、リモート接続だけで障害が発生することがあります。ローカルメディアの再生とリモート接続性は、別々の受け入れテストとして扱ってください。

ネットワーク容量は実際の配信エッジで確認する必要があります。ストリーミング帯域幅モデルを使えば、すべての再生障害をサーバーの処理能力の問題として扱うのではなく、LAN、Wi-Fi、NAS、リモート側のアップロード帯域の制限を切り分けられます。

まず有線接続のローカルクライアントで確認し、次にリモートクライアントを1台確認してください。ローカル再生が正常なら、サーバーの状態を再構築するのではなく、残る修復作業をルーティング、DNS、プロキシ、またはトンネルの構成に限定してください。