コンテナ再起動後にJellyfinの動作が異なる場合がある理由
Jellyfinは、永続データが保持される一方で、マウント、デバイス、起動タイミング、ネットワークパス、キャッシュが再構築されるため、再起動後に異なる動作をすることがあります。
ライブラリ自体は残っていても、プロセスから見えるデバイスの準備状態が異なっていたり、依存先が利用可能になる前に起動したりする場合があります。また、キャッシュが空の状態では、基盤となるカタログを変更せずに最初のリクエストだけが遅くなることもあります。違いをデータ破損と判断する前に、永続状態と実行時の条件を分けて考えてください。
永続状態と実行時状態は異なります
設定、データベースファイル、ユーザー、ライブラリ定義は、コンテナの外部に永続化できます。一方、マウント、環境変数、デバイス権限、ネットワークID、プロセスのタイミング、メモリ内キャッシュは、毎回再作成されます。
永続データの役割の解説を使うと、再起動後も維持されるべき動作と、変化して当然の動作を見分けやすくなります。
したがって、再起動後の違いは、Jellyfinがライブラリを失った証拠とは限りません。
起動順序によって最初の結果が変わることがあります
ストレージ、GPUデバイス、ネットワークマウント、依存サービスの準備が異なるタイミングで完了すると、Jellyfinが不完全な環境を前提に初期化されることがあります。その場合、設定ファイルが同一でも、同じイメージから異なる起動経路になる可能性があります。
再起動の手順を、永続データを中心に実行時の条件が再構築されるアップグレード後の分析モデルと比較してください。
その後の再起動で正常な動作に戻るなら、完全に破損したデータベースよりも、タイミングや準備状態が原因である可能性が高くなります。
キャッシュが空だとサービスの動作が異なるように感じられます
再起動後は、データベースのページ、アートワーク、ディレクトリエントリ、トランスコードの状態がキャッシュされていないことがあります。そのため、最初のライブラリ表示やストリーミングは、繰り返し実行した場合より遅くなることがあります。作業セットが再構築されれば、通常の状態に戻ります。
1回目と繰り返し実行時の所要時間を比較するには、1回のキャッシュが空のリクエストだけでサービスを判断するのではなく、キャッシュが空の状態と温まった状態でのベンチマーク手法を利用してください。
初回利用時の遅延だけが変化するなら、境界となっているのはキャッシュの状態である可能性が高くなります。すべてのリクエストで変化するなら、マウント、デバイス、リソース競合を確認してください。
データを変更する前に違いを分類する
何が変化したのかを記録してください。ライブラリの表示状態、ユーザー状態、再生モード、デバイスアクセラレーション、ネットワーク到達性、それとも初回リクエストの所要時間だけなのかを確認します。そのうえで、原因を説明できる最小限の実行時変数を比較してください。
永続データの役割を、通常の再起動による変動と永続状態の障害に分けて考えることで、復旧作業の範囲を限定できます。
確認された違いを説明できる最初の条件で調査を止めてください。その分類を行わずにデータを再構築または削除すると、実行時の問題がデータ消失につながる可能性があります。
おすすめ商品
テック＆AIハブ
もっと読む
ローカルAIゲートウェイは、GPUの割り当て前に厳格なコンテキスト上限を適用できますか？
ハードコンテキストゲートの仕組みを優先した説明、その共有リソースに関するトレードオフ、クエリファンアウトに関する3つのよくある質問、そして実践的な検証プロトコル。
ホームAIサーバーは、2.5GbE経由でリモートNASのモデル重みをメモリマップできますか？
リモートNASモデルのメモリマッピングに関するメカニズム重視の説明、共有リソースのトレードオフ、クエリのファンアウトに関する3つのFAQ、そして実践的な検証手順。
複数のコンテナで1つの内蔵GPUを共有しても、ワークロードが漏洩することはない？
共有iGPUコンテナ分離のメカニズムを第一にした説明、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、そして実践的な検証手順。
