ユーザーが誰もアクティブでないとき、Jellyfinがドライブをスリープさせないのはなぜですか？
Jellyfinは、アクティブな視聴者がいなくてもドライブをスリープ状態から復帰させることがあります。再生だけがディスクアクティビティの原因ではないためです。スケジュールされたライブラリ処理、メタデータ操作、ログ記録、データベースアクセス、ストレージチェックなどは、サーバーがそれ以外ではアイドル状態でも実行されます。
最も迅速な診断方法は、そもそもJellyfinが原因かどうかを確認することです。アイドル時間中のディスクアクティビティを観察し、Jellyfinのコンテナまたはサービスだけを停止して、復帰パターンが止まるか確認します。この比較だけで、実際の原因がSMARTポーリング、インデックス作成、バックアップ、または別のホストサービスなのに、便利なライブラリタスクを無効にしてしまう事態を防げます。
Jellyfinを停止すると復帰が止まるか確認する
ユーザー、ダウンロード、バックアップ、メディアのインポートがない静かな時間帯を選びます。どのディスクがどの程度の頻度で復帰するかを記録し、その後ホストを再起動せずにJellyfinを停止します。大きな変動要因をJellyfinプロセスだけにするため、ストレージはマウントしたままにしてください。
十分な観察時間のあいだに復帰が止まった場合は、Jellyfin内部の調査を続けます。変化せずに復帰が続く場合は、ホスト、NAS、ファイルシステム、または他のコンテナを調べてください。再起動は一度に多くのサービスを変更してしまうため、最初のテストとしては適していません。
比較後にJellyfinを再起動し、スケジュールを変更する前にパターンが再び現れることを確認します。起動時に一度だけ復帰することと、数分おきに繰り返しアイドル復帰することは異なります。修正対象は通常のサービス初期化ではなく、繰り返し発生するトリガーにすべきです。
スケジュールされたタスクとライブラリスキャンを確認する
Jellyfinのダッシュボードを開き、スケジュールされたタスクの最終実行時刻、所要時間、次回の実行タイミングを確認します。ライブラリスキャン、メタデータの更新、画像処理、メンテナンスタスクは、誰も視聴していないときでもディレクトリを読み取ることがあります。
Jellyfinのソースドキュメントでは、サーバー内に専用のScheduledTasks領域があることが示されています。また、ストレージに関するガイダンスでは、スケジュールされたメンテナンスがライブラリの内容に対して実行される可能性が説明されています。 スケジュールタスクサブシステム
ディスクの復帰が特定のタスクと一致する場合は、そのタスクを計画したメンテナンス時間帯に移動するか、ライブラリの運用上問題がない場合に限って頻度を下げます。すべてのタスクを一度に無効にしないでください。どのスケジュールが原因だったのか特定できなくなります。
メタデータとチャプター画像の処理を確認する
ライブラリによっては、他のライブラリよりも負荷の高いバックグラウンド処理が実行されます。チャプター画像、トリックプレイ関連データ、字幕の抽出、メタデータの更新などは、再生とは無関係に見える読み書きのバーストを発生させることがあります。
Jellyfinのドキュメントでは、チャプター画像の抽出は計算負荷が高い処理であり、専用のスケジュール抽出タスクとして、またはライブラリスキャン中に実行できると説明されています。 チャプター画像の抽出 そのため、静かな時間帯にディスクが復帰するサーバーでは、このスケジュールを確認する価値があります。
疑わしい抽出ジョブを一時的に既知の時刻へ移動し、ディスクのパターンを比較します。復帰のタイミングがタスクに合わせて移動するなら、原因を明確に特定できます。変化しない場合は、原因ではなかった機能を恒久的に無効にせず、スケジュールを元に戻して調査を続けてください。
メディアディスクのアクティビティをデータベース、キャッシュ、ログのアクティビティから切り分ける
Jellyfinは、すべての種類のデータをメディアディスクに書き込むわけではありません。データベース、設定、キャッシュ、ログ、メタデータは別のボリュームに保存されている場合があるため、まず実際にどの物理ディスクが復帰しているのかを特定してください。
Jellyfinはデータベースをローカルストレージに置くことを推奨しています。また、標準的なメディアサーバー構成にすると、アプリケーションデータとメディアのパスを分離しやすくなります。設定とデータベースを保存しているSSDだけがアクティブなら、回転式のメディアディスクにJellyfin側の変更は必要ない可能性があります。
メディアタスクが実行されていないのに回転式のメディアディスクが復帰する場合は、ライブラリパスと、有効にしている「メディアと同じ場所にメタデータを保存」する動作を確認します。目的は、Jellyfinが動作しているという事実だけを根拠に推測することではなく、書き込み負荷が高いと確認できた処理だけを移動または再スケジュールすることです。
競合する原因としてネットワークマウントとホストサービスを確認する
NASや外付けディスクは、オペレーティングシステムがマウントを確認したり、監視エージェントがファイルを問い合わせたり、バックアップジョブがディレクトリを走査したり、ストレージデバイス自体がヘルスチェックを実行したりすることで復帰する場合があります。これらはJellyfinが完全にアイドル状態でも続くことがあります。
ネットワーク上のメディアについて、JellyfinはSambaまたはNFSのストレージがオペレーティングシステムによってマウントされていることを前提としています。 マウントされたネットワークストレージ つまり、一部のディスクアクティビティはアプリケーションではなく、ホストまたはNASの層から発生している可能性があります。
Jellyfinを停止しても復帰パターンが変わらない場合は、Jellyfinの設定を変更しないでください。競合しているホストタスクを一度に1つずつ無効化または再スケジュールするか、ホスト上でプロセス単位のI/Oツールを使用して、電源管理を変更する前に読み取り元を特定します。
ライブラリの信頼性を損なわずに復帰を減らす
原因を特定できたら、変更は最小限にとどめます。スキャンを固定した時間帯に移動する、不要な抽出スケジュールの頻度を下げる、アプリケーションデータをSSDに置く、または別のサービスがメディアツリーを走査しないようにする、といった対応です。ライブラリを正確に保つために必要なタスクは維持してください。
リモートストレージや、常時利用できるとは限らないストレージに対して、過度に積極的なディスクスリープを設定する場合は注意が必要です。Jellyfinは、タスクの実行時にメディアストレージが利用できないと、スケジュールされたメンテナンスによってライブラリ項目が削除される可能性があると警告しています。そのため、省電力動作によってマウントが存在しないように見えないようにしてください。 メンテナンスタスクに関するストレージの注意事項
少なくとも1回の完全なアイドル時間帯と、次回のスケジュール済みメンテナンス時間帯を通して修正を検証します。意図したアイドル時間中にディスクがスリープ状態を維持し、次回のスキャンや再生も正常に動作することを確認できたら完了です。両方の目標が両立しない場合は、数回の余分な復帰よりも信頼性を優先してください。
おすすめ商品
サポートとヒント
もっと読む
Home Assistantを稼働中にバックアップすべきか、それとも先にサービスを停止すべきか？
Home Assistantの組み込みバックアップは稼働中でも実行できますが、単純なファイルシステムのコピーでは、データベースを一貫性のある状態でバックアップしない限り、Home Assistantを停止または休止させる必要があります。
アイドル時間中にHome Assistantサーバーが高温になったり、うるさくなったりするのはなぜですか？
冷却やCPU制限を変更する前に、Recorder、バックアップ、連携機能、同一ホスト上のジョブと、Home Assistantのファン回転数や温度の急上昇との相関を確認してください。
Home Assistantは修理するより再構築すべきなのはいつですか？
まず、Home Assistantで最小限の故障レイヤーを修復し、次に既知の正常な状態へ復元します。永続設定を信頼できない場合にのみ再構築してください。
