アップグレード後にJellyfinが既存のメディアを再処理することがある理由
Jellyfinでは、アップグレード後に解析ロジックや保存済みメディア属性が変更されると、元のファイルに変更がなくても既存のメディアを再処理することがあります。
新しいバージョンでは、再生や照合に必要な新しい解析データが求められる場合があり、既存のライブラリ全体でCPUやディスクの処理が発生します。この有限のキューは、スキャン、メタデータの更新、または永遠に繰り返されるジョブとは異なります。処理を異常と判断する前に、進行状況と完了を確認してください。
メディアに変更がなくても解析データは変わる
サーバーが追加のプロパティを取得したり、既存ファイルの解釈方法を修正したりすることがあります。これらの属性を再計算するために、元のファイルのタイムスタンプを変更する必要はありません。
アップグレード後の解析モデルの解説では、バージョン変更によって発生する有限のキューが正常な場合がある理由を説明しています。
最初に確認すべきなのは、メディアが追加されたかどうかではなく、キューが進行して収束するかどうかです。
再解析、スキャン、更新は異なる
スキャンはパスを確認して追加や削除を検出し、メタデータの更新は説明情報を更新します。一方、メディア解析は再生に使用されるファイルのプロパティを調べます。ダッシュボード上では重なって表示されることがありますが、トリガーとI/Oのパターンはそれぞれ異なります。
永続データの役割の状態モデルを使うと、データベースやメタデータの処理をメディアファイルそのものから分けて考えられます。
同じ項目が進展なく繰り返される場合、それは一度限りの解析変更では説明できない状態です。
正常と判断できる境界は処理が有限であること
アップグレード後の正常なキューは、増加または進行し、完了に達した後、再起動しても完了状態を維持します。同一のジョブが繰り返される、パスが見つからない、権限エラーが発生する、データベースエラーが発生するといった場合は、別の運用上の問題が考えられます。
アップグレード後の解析モデルで示される、有限のキューと繰り返される処理の違いが重要な判断基準になります。
キューが進行しているなら、処理中だからという理由だけで中断しないでください。ただし、処理がまったく減らない、または再起動するたびに戻ってくる場合は調査してください。
介入する前に完了を確認する
キューのサイズ、処理済み項目数、CPUやI/Oのアクティビティ、そして管理下で一度再起動した後も完了済み項目が完了状態を維持するかを記録してください。観察期間中は、スキャンや更新を強制的に実行しないようにします。
コールド／ウォームベンチマークのベンチマーク手法を使い、キューを観察する間はバックグラウンド処理とキャッシュの状態を一定に保ちます。
キューが処理し終わり、通常のアイドル状態に戻ったら終了します。同じ条件下で繰り返し、エラー、またはパスの喪失が続く場合にのみ、詳しい調査へ進んでください。
おすすめ商品
テック＆AIハブ
もっと読む
ホームカメラはクラウドの時刻サービスなしでイベントを同期できますか？
クラウドを使わないカメラ時刻の仕組みを優先した説明、共有リソースに伴うトレードオフ、クエリのファンアウトに関する3つのFAQ、そして実践的な検証手順。
ローカルAIサービスは推論前に破損したモデルレイヤーを検出できますか？
破損したモデル層の検出について、メカニズムを優先して説明し、共有リソースのトレードオフ、クエリのファンアウトに関する3つのFAQ、実践的な検証プロトコルを取り上げます。
すべての埋め込みを再生成せずにRAGシステムを復元できますか？
再埋め込みなしでRAGを復元する仕組み優先の説明、共有リソースのトレードオフ、クエリファンアウトに関する3つのFAQ、そして実践的な検証プロトコル。
