コミュニティソリューション

ZimaOSでJellyfinのCPU使用率が高い:ライブラリのインデックス作成が止まっている可能性が高い場合

A March 2026 ZimaOS thread where Jellyfin stayed near full CPU utilization for two days and stopped loading normally after about 90 GB of media was added, prompting community checks for stuck background tasks, media issues, storage availability, and hardware acceleration.

Jellyfinで最初にライブラリをスキャンする際にCPU使用率が高くなるのは想定されることがあります。しかし、Jellyfinのインターフェースに読み込みスピナーしか表示されないまま、サーバーのCPU使用率が数日間にわたってほぼ100%に張り付く場合は、別の状況です。2026年3月のこのZimaOSスレッドでは、ユーザーが約90 GBの動画を追加した後も、2日目になって高いCPU使用率が続いていました。

このスレッドでは根本原因が確認されないまま終わっているため、このページは解決済みの事例に基づく手順ではなく、診断ガイドとして利用してください。

ZimaOSでライブラリのスキャン中にJellyfinのCPU使用率を比較する際に共有されたシステムアクティビティのスクリーンショット
コミュニティの返信には、Jellyfinの使用経験では2日間にわたってCPU使用率がほぼ100%で継続するのは一般的ではないと主張する際に、このシステムアクティビティのスクリーンショットが添付されていました。

初回処理に数時間かかるのは正常な場合がありますが、数日間続き、UIが固まるのは正常ではありません

コミュニティの別のユーザーは、CPU使用率がフル状態で2日間継続することを通常のインデックス作成とみなす考えに異議を唱えました。ある回答者は、より古いハードウェアでもスキャン時の使用率ははるかに低かったと報告し、別の回答者は、JellyfinがCPUを消費しながら読み込みにも失敗していることから、このケースは停止している可能性が高いとまとめました。

固定されたCPU使用率の基準値よりも、この区別の方が有用です。ライブラリのサイズ、サムネイル、チャプター画像、メタデータのダウンロード、コーデックの解析、ストレージ速度によって、初回スキャンで必要となる処理量は変わります。

Jellyfinは単純なファイルインデックス作成以上の処理を実行します

現在のJellyfinドキュメントには、ライブラリスキャン、チャプター画像の抽出、キーフレームの抽出、字幕のダウンロード、データベースの最適化、キャッシュのクリーンアップなど、スケジュールタスクとして実行されるさまざまな処理が記載されています。

Jellyfinが実行できるバックグラウンドタスク

メディアの検出が安定するはずの時間を大幅に過ぎてもCPU使用率が高いままの場合は、サーバーが通常のライブラリスキャンを続けていると決めつけず、実際にどのバックグラウンドタスクが実行されているのかを確認してください。

プレビューとチャプター画像の生成には大きな負荷がかかる場合があります

コミュニティの返信では、CPU使用率が低下するか確認するため、プレビューサムネイルとチャプター画像の生成を一時的に無効にすることが提案されました。これはトラブルシューティングの提案であり、元の投稿者に対する確認済みの解決策ではありません。

現在のJellyfinタスクドキュメントでは、チャプター画像とキーフレームの抽出が実際のバックグラウンドジョブであることが確認されています。そのため、起動時の処理が異常に長く続くように見える場合は、確認すべき有効な項目です。

利用できない、またはスリープ中のストレージがメディア処理の失敗を繰り返させることがあります

このスレッドでは、USBまたはDASのスリープや接続解除も原因の可能性として挙げられました。メディアのパスが消えたり、一時的に利用できなくなったりすると、繰り返されるスキャンやメディアアクセスの失敗が、インデックス作成の問題のように見えることがあります。

Jellyfinのバージョンを変更したり、アプリケーションを再構築したりする前に、すべてのライブラリパスがマウントされたままで、正常に応答することを確認してください。

トランスコードとハードウェアアクセラレーションは別のCPU負荷です

対象のマシンには、第12世代のIntel Core i7-1255UとIris Xeグラフィックスが搭載されていました。JellyfinはLinux上で、コンテナ、デバイスへのアクセス、ドライバー、Jellyfinの設定が正しく構成されていれば、Intel Quick SyncとVA-APIによるハードウェアアクセラレーションをサポートしています。

JellyfinでIntel Quick SyncとVA-APIを構成する方法

ただし、このスレッドでは、GPUアクセラレーションが利用できなかったことが、元の2日間にわたる負荷の原因だとは証明されていません。ハードウェアアクセラレーションが主に関係するのは、Jellyfinが実際にトランスコードを実行している場合、または対応するアクセラレーション対応メディア処理を行っている場合です。

あるユーザーがバージョン固有の回避策を報告しました

コミュニティのメンバーの1人は、まずJellyfin 10.10.7を設定し、その後10.11.6にアップグレードすることで、起動時の問題が減ったと述べています。これは個人の経験であり、JellyfinまたはIceWhaleによる公式の推奨ではありません。

その1件の返信だけを理由に、Jellyfinをダウングレードしたり、特定のバージョンに固定したりしないでください。使用している環境の現在のイメージバージョン、リリースノート、ログを確認してください。

より適切なトラブルシューティングの順序

  1. Jellyfinのダッシュボードが読み込めるか確認する。
  2. 継続的に実行されているスケジュールタスクまたはライブラリタスクを確認する。
  3. すべてのメディアパスがマウントされ、読み取り可能であることを確認する。
  4. 必要に応じて、負荷の高いプレビューやチャプター画像の処理を一時的に減らす。
  5. ライブラリスキャンによるCPU負荷と、実行中の動画トランスコードを切り分ける。
  6. トランスコードが問題の一部である場合に限り、ハードウェアアクセラレーションを確認する。
  7. 再インストールする前に、繰り返し処理されているファイルやエラーがないか、Jellyfinアプリケーションのログを確認する。

JellyfinのCPU使用率が高い場合のFAQ

Jellyfinの初回スキャン中にCPU使用率が100%になるのは正常ですか?

短時間であれば起こり得ますが、このスレッドでは、CPU使用率の高さが2日間続き、UIも使用できない状態を正常とはみなしていません。

サムネイルやチャプター画像によってCPU使用率が上がることはありますか?

はい。Jellyfinにはチャプター画像とキーフレームの抽出タスクが記載されており、コミュニティでは診断テストとして、それらを一時的に無効にすることが提案されました。

スリープ中のUSBドライブがスキャンの繰り返しを引き起こすことはありますか?

メディアが利用できなくなり、エラーや処理の繰り返しが発生する可能性はあります。このスレッドでは、ストレージの可用性は原因の候補の1つとして挙げられましたが、確認された原因ではありません。

元の問題は解決しましたか?

このスレッドには、確認済みの最終的な解決結果は投稿されていません。