ライブラリ変更後にJellyfinのバックグラウンド処理が急増する理由

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Jellyfin Background Work Spikes After a Library Change - Zima Store Online

Jellyfinのバックグラウンド処理は、ライブラリを変更した後に急増することがあります。これは、1つのファイルシステムイベントが、検出、メタデータ、画像、データベース、生成メディアの各タスクへ波及するためです。

シーズンフォルダーの追加は単一のストレージ操作に見えますが、サーバーは何が変更されたのかを判断し、新しい項目を照合し、メタデータを取得または読み込み、インデックスを更新し、必要に応じてサムネイルやトリックプレイ用アセットを生成しなければなりません。小規模なNASでは、これらの段階が再生処理と重なり、原因の分からないCPUまたはディスク使用量の急増として現れることがあります。この急増が正常なのは、その依存関係の連鎖が制御され、処理を完了できる場合に限られます。

ファイル変更は識別パイプラインを開始する

最初の仕事はアートワークのダウンロードではありません。パスを検出し、メディアの種類を識別し、既存のライブラリレコードのうち追加、変更、削除が必要なものを判断することです。大規模な名前変更は、削除と追加の組み合わせとして扱われることがあり、比較や書き込みが増加します。

運用担当者からは、初回スキャンと増分スキャンでは挙動が異なるという報告があります。初回スキャンでは、より多くの状態を登録する必要があるためです。チャプター画像やトリックプレイの抽出によって、基本的な検出処理よりも作業が長引くこともあります。

この関係は相乗的です。変更されたパスが増えるほど識別の判断が増え、名前付けが曖昧であるほどプロバイダーへの照会が増えます。整理された構造は不確実性を減らしますが、必要なインデックス更新をなくすことはできません。

メタデータと画像が項目ごとの作業を増やす

識別後、Jellyfinはローカルメタデータを読み込み、プロバイダーに問い合わせ、画像を選択し、アートワークのサイズを変更し、各種クライアントで使用されるレコードを書き込むことができます。1つのタイトルから、複数の永続アセットや、時間の経過とともに複数の表示サイズのバリエーションが作成されることがあります。

メタデータを整理することでJellyfinの動作が改善した事例では、ライブラリの正確性と、生のトランスコード性能が切り分けられています。誤った照合や重複した構造は、再生能力を高めることなく、繰り返しの作業を増やします。

そのため、ネットワーク、CPU、ディスクのアクティビティが同時に上昇することがあります。プロバイダーへのリクエストはインターネットの応答を待ち、画像処理には計算資源が使われ、データベースやアセットの書き込みにはストレージが使われます。1つの使用率グラフだけでは、連鎖全体を表せません。

生成メディアはスキャン後も処理が続くことがある

チャプター画像、プレビュー、イントロ検出、トリックプレイの生成では、カタログがすでに登録済みに見えた後も、メディアの読み込みやデコードが行われます。こうしたタスクは、画面上のスキャンが完了した後も長く動作し続けることがあり、再生に必要なCPU、GPU、ディスクを同じように使用する場合があります。

バックグラウンドタスクの分類についての調査では、ライブラリスキャン、メタデータの更新、画像抽出、イントロ関連の処理が別々のジョブとして取り上げられています。これらが重なることで、「完了した」スキャンが必ずしもサーバーのアイドル状態を意味しない理由が分かります。

ワークロードを左右するのは単なる項目数ではなく、有効になっている機能と変更されたメディアです。動画由来のアセット生成が発生する場合、大きなファイルを1つ置き換える方が、多数のテキストフィールドを修正するよりコストが高くなることがあります。

Featured

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

ZimaCube2

急増が正常ではなくなるタイミング

既知の変更に続いて発生し、測定可能な進捗があり、基準値に戻っていくなら、その急増は想定内です。同じパスが何度も再検出される、プロバイダーが継続的に再試行する、ストレージが認識されなくなる、生成アセットが空き容量を使い果たすといった場合は、通常の波及処理ではありません。

空きストレージの境界が重要なのは、アセットやキャッシュの増加が一時的なアクティビティを継続的な障害へ変える可能性があるためです。空き容量が少ないと、データベースへの書き込みやコンテナの動作も予測しにくくなります。別の現場レポートでも、目に見える症状からボトルネックを決めつけるのではなく、スケジュールタスクの進捗を確認することが推奨されています。

変更前後の記録を作成しましょう。変更されたパスの数、タスク名、開始時刻と終了時刻、データベースの増加量、生成アセットの増加量、再生への影響を記録します。変更のない2回目のスキャンが1回目と同じコストを繰り返す場合は、より高速なハードウェアを購入するのではなく、繰り返しのトリガーを調査してください。