サムネイルの生成でメディアサーバーのアプリストレージがいっぱいになるのはなぜですか？
サムネイルの生成によってアプリのストレージが圧迫されるのは、サーバーが多数の派生画像を作成し、それらを書き込み可能なメタデータまたはキャッシュのパスに保存するためです。
メディアライブラリでは、数テラバイトの動画をHDDプールに保存する一方、コンテナの設定、メタデータ、キャッシュをはるかに小容量のSSDやブートボリュームに割り当てている場合があります。チャプター画像、トリックプレイプレビュー、ポスター、背景画像、一時的な展開ファイルは、元ファイルのサイズだけでなく、ライブラリの稼働時間や生成設定に応じて増加します。安全な対処は、データベースがまだ必要としているファイルを削除する前に、正確な派生データの種類と保存先を特定することから始まります。
実際に増加しているディレクトリを特定する
メディアアプリケーションの設定、キャッシュ、メタデータ、トランスコード、一時ディレクトリを個別に測定します。サムネイル処理の実行中に、サブディレクトリを割り当て済みサイズと最終変更時刻の新しい順で並べ替えます。
Jellyfinのインターフェース文字列では、チャプター画像の抽出について、処理に時間がかかり、リソースを大量に消費し、数ギガバイトの空き容量が必要になる可能性があると明記されています。
容量の増加先が、ホストのバインドマウント、名前付きボリューム、コンテナの書き込み可能レイヤーのいずれであるかを確認します。コンテナレイヤーが増加している場合は、クリーンアップの前に永続化を修正してください。そうしないと、アプリ上では容量が消えたように見えても、Dockerのシステムストレージを消費し続ける可能性があります。
どの画像機能がファイルを作成したか特定する
通常のポスターや背景画像と、チャプター画像、トリックプレイプレビュー、動画プレビューのサムネイル、イントロマーカー、プラグインが生成したアートワークを分けて確認します。各機能には異なる生成条件と保持ルールがあります。
トリックプレイは、動画のタイムライン全体から繰り返し視覚サンプルを作成し、クライアントがシーク中にプレビューを表示できるようにします。生成される画像グリッドの規模は、元動画が1080pか4Kかよりも、主に再生時間、サンプリング間隔、解像度、画質、タイルレイアウトによって決まります。
スケジュールタスクを1つ手動で実行し、対象ディレクトリを監視します。新しいファイル名とデータベースのエントリを、生成元の機能と照合します。1つのプレビュータスクだけが原因の場合は、すべてのメタデータプロバイダーを無効にしないでください。
間隔、解像度、画質、対象ライブラリを確認する
サムネイルの幅、サンプリング間隔、JPEGまたはWebPの画質、タイルの寸法、スレッド数、生成対象に含めるライブラリを記録します。間隔を短くし、画像を大きくすると、動画1時間あたりに保存されるピクセル数が増えます。
設定変更やアップグレードの後に、生成が再開されることもあります。JellyfinのIssueには、機能を無効にしても既存の出力が削除されず、以前に生成されたトリックプレイデータが再び作成されるのを止められなかったユーザーの事例が記載されています。
小規模なテストライブラリで設定を1つだけ変更し、メディア1時間あたりに生成されるバイト数を比較します。その実測値を使ってライブラリ全体の容量を見積もってから、別の全体抽出タスクを開始します。
| 設定変更 | 予想されるストレージへの影響 | トレードオフ |
|---|---|---|
| サンプリング間隔を長くする | 画像数が減る | シークプレビューの精度が下がる |
| サムネイルの幅を狭くする | ファイルサイズが小さくなる | テレビで表示するプレビュー画像がぼやける |
| 画像品質を下げる | ファイルサイズが小さくなる | 圧縮アーティファクトが増える |
| ライブラリの対象範囲を狭める | 必要な総容量が減る | 対象外のライブラリにはプレビューが作成されない |
すべてのタイトルに最高品質の派生データを生成するのではなく、実際のクライアント画面とシーク操作に合った設定を選択します。
古い、または孤立したサムネイルセットを探す
ファイルの置き換え、名前変更、移動、削除の後に、現在のメディア項目と生成済みディレクトリを比較します。新しいファイルに別の項目IDや出力名が割り当てられると、古いプレビューセットが残ることがあります。
Jellyfinの報告では、新しいプレビューを生成しても、メディアの隣に保存されていた古いトリックプレイ画像が削除されず、古いトリックプレイデータが現在のセットの隣に残っていました。
まずアプリケーションがサポートするクリーンアップタスクを使用し、メタデータデータベースのバックアップがあることを確認します。手動削除が必要な場合は、孤立していることを確認した1項目でテストし、更新してから、参照関係が不明な大規模ディレクトリツリーを削除します。
画像をアプリのストレージに置くべきか、メディアの隣に置くべきか確認する
メディアサーバーによっては、アートワークやトリックプレイデータをライブラリの隣に保存できますが、データベースに紐付いた派生データをアプリのメタデータ内に保持するものもあります。保存場所を移動すると、バックアップ、権限、移行、読み取り専用メディアの動作が変わります。
プレビューをメディアの隣に保存すると、移行時の可搬性が向上する場合があります。しかし、大容量のHDD共有上で小さなファイルが大量に増え、ライブラリへの書き込み権限が必要になることもあります。Jellyfinの移行に関するIssueでは、メディアの隣にローカル保存されたトリックプレイファイルは、インスタンス間で正常に移行できない場合があることが示されています。
アプリケーションがポータブルなローカル画像を完全にサポートしている場合を除き、データベースに紐付いた派生データや頻繁に更新される派生データは、容量を意図的に確保したアプリボリュームに保存します。選択した構成で書き込みが不要な場合は、メディア共有を読み取り専用にします。
データベースの状態を分割せずにアプリボリュームを移動する
設定に問題がなく、アプリボリュームの容量だけが不足している場合は、メディアサーバーを停止し、コンテナの永続マウント設計に従って、設定、メタデータ、キャッシュの各領域全体を移動します。所有者、ACL、データベースファイル、シンボリックリンクを保持してください。
メタデータとサムネイル向けのSSDアプリボリュームに関するZimaSpaceの記事では、大容量の元メディアをHDDに残したまま、こうした小さなファイルを扱う処理が高速ストレージの恩恵を受ける理由を説明しています。
アプリケーションがその分割構成をサポートしている場合を除き、データベースのパスを残したまま最大の画像フォルダーだけを移動しないでください。移行したインスタンスを分離した状態で起動し、再生成を行う前に古いサムネイルが正しく表示されることを確認します。
安全にクリーンアップし、増加量の基準を作る
サムネイルタスクを一時停止し、アプリケーションデータベースをバックアップして、派生データの種類ごとに現在のファイル数と容量を記録します。確認済みの古い出力だけを削除するか、アプリケーションがサポートする削除および再生成の機能を使用します。
SSDの容量不足はサムネイル以外にも影響します。JellyfinのIssueでは、SSDの枯渇とデータベースの破損の疑い、不完全なライブラリ表示が関連付けられており、空き容量の枯渇がアプリの状態を脅かす可能性が示されています。
クリーンアップ後は、1つのライブラリで生成を実行し、1日あたりの増加量を測定します。アプリボリュームが予備容量のしきい値に達する前にアラートを設定してください。期待したプレビューが動作し、古いデータが再び作成されず、ストレージの増加量が選択した間隔、解像度、画質、ライブラリ範囲と一致していれば、修復は完了です。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
