リモート4Kストリーミング中にPlexのメタデータが増加する原因とは？

エヴァ・ウォン

IceWhale author

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

What Causes Plex Metadata Growth During Remote 4K Streaming?

リモート4KストリーミングだけでPlexのメタデータが長期的かつ大幅に増加することは、通常ほとんどありません。多くの場合、サムネイル、分析、データベースの変更、またはトランスコード用の一時データが原因です。

リモートセッションでは、一時バッファ、ログ、変換出力が作成されることがあります。一方、長期的に残るアプリケーションデータは別の理由で増加します。動画プレビュー画像、チャプターサムネイル、アートワーク、インデックス、データベースレコードは、ライブラリの変更や分析機能の実行に伴って蓄積されます。重要なのは、再生停止後も容量が残るか、視聴に伴って増えるのか、新しいメディアの追加に伴って増えるのか、バックグラウンド分析に伴って増えるのかを見極めることです。

リモート4K再生が永続的なメタデータ生成の主因になることは通常ありません

4Kファイルをリモートでストリーミングすると、セッション状態やログ、場合によっては一時的なトランスコード出力が生成されます。しかし、これは長期的に残るライブラリメタデータの増加とは異なります。永続的な増加は、ライブラリの規模や、アートワーク、インデックス、サムネイル、追加のデータベースレコードを生成する機能に関係することが多いです。

ユーザーによるプレビューサムネイルのストレージの測定結果からは、ライブラリによっては派生画像が元のメタデータ容量を大きく上回ることが分かります。重要なのは、容量の増加が視聴者がたまたまリモートでストリーミングした事実ではなく、有効化された分析機能とライブラリの規模に伴っている点です。

新しいメディアを追加せず、リモートのみのセッションを実行する前後でPlexのデータディレクトリを測定し、その後、新しいタイトルを追加して分析した後の変化と比較してください。前者の変化が小さく、後者が大きい場合、永続的なメタデータの増加はリモート4K配信ではなく、ライブラリ処理によるものです。

動画プレビューサムネイルがメタデータ容量の大部分を占めることがあります

プレビューサムネイルは動画全体からフレームをサンプリングし、クライアントがシーク中に画像を表示できるようにします。メディアファイル自体は元の場所に残りますが、生成された派生データはPlexのアプリケーションデータとともに保存されます。長時間の動画や大規模なライブラリでは、元のファイルが1080pか4Kかに関係なく、このストレージコストが増加します。

設定に関するガイダンスでは、プレビューサムネイルのストレージによって、分析済みメディア用の一連の画像が作成されると説明されています。大規模な既存ライブラリ全体で有効にすると、最初に一度大きく容量が増加し、その後は新しいメディアの追加に応じて緩やかに増加することがあります。

メタデータとメディアのサブディレクトリは、データベースファイルとは分けて確認してください。そうすれば、大きな派生データの保存領域をデータベースの肥大化と誤認せずに済みます。サムネイルストレージが主な増加要因であれば、データベースのメンテナンスに手を付ける前に、その機能の操作性向上が必要な容量に見合うか判断してください。

チャプターおよび分析ジョブは、変更後に派生データを再生成することがあります

Plexがメディアを変更済みと判断し、派生データの処理を再度スケジュールすると、メタデータが増え続けることがあります。ファイルの置き換え、分析の更新、ライブラリ項目の修正によって、すでにインデックス化されたコンテンツに対してチャプターやプレビューのジョブが再実行される場合があります。新しいメディアの追加に比例した安定した増加よりも、同じデータの繰り返し処理のほうが疑わしい兆候です。

エクストラを削除した後もPlexがチャプターサムネイルを再生成し続けた事例は、古い状態や予期しない項目の状態によってバックグラウンド処理が継続する可能性を示しています。重要なのは、フォルダーを手動で削除する前に、どの項目に伴って容量が増えているかを特定することです。

アプリケーションデータのディレクトリが増加している間に、ログへどのメディアIDが記録されているか確認してください。同じ削除済みまたは変更済みの項目が繰り返し現れる場合は、まずライブラリの状態を修正します。新しく追加した項目がそれぞれ正常に処理されている場合、その増加は暴走したループではなく、想定される派生データの蓄積です。

Featured

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

ZimaCube2

データベースの増加はアートワークの増加とは異なる兆候です

メインのライブラリデータベースには、実際のポスター画像や動画フレームではなく、関連関係、状態、各種レコードが保存されます。ライブラリの複雑さやアクティビティに伴ってサイズが増加することはありますが、クエリの遅延や破損警告を伴う急速なデータベース肥大化は、サムネイルの保存領域が健全に増えている場合とは別の問題です。

ある報告では、データベースの急速な肥大化に加えて、ライブラリの動作遅延や最終的な破損が発生していました。このような組み合わせは、容量を確保するために任意のメタデータを削除するのではなく、健全性に関する兆候として扱ってください。

数日間にわたり、データベースファイルと派生データのディレクトリを別々にグラフ化してください。ライブラリに対応する変更がないのにデータベースが急増する場合は、整合性とログを確認する必要があります。分析後に派生データのディレクトリが予測どおり増加する場合は、機能設定、保存場所、容量計画によって管理できます。

トランスコード用の一時データを永続的なメタデータとして数えないでください

リモート4K再生で変換が必要になると、Plexは一時的なトランスコードデータを書き込んだり、バッファリングしたりします。このストレージはアクティブなセッション中に増加し、後から縮小することがあるため、誤ったパスを監視すると、一時的な出力が永続的なメタデータの増加に見えることがあります。各ディレクトリの用途とライフサイクルは、ディレクトリ名そのものよりも重要です。

設定、メディア、トランスコードの保存場所を分離するのは、コンテナでよく使われる構成です。Dockerの構成では、設定とトランスコードの役割を別々のデータパスとして説明しています。この分離により、永続的なライブラリ状態と破棄可能な変換出力を簡単に区別できます。

アプリケーション用ストレージを拡張する前に、増加している各ディレクトリをデータベース、メタデータ、キャッシュ、トランスコード用の一時領域のいずれかに割り当て、停止中や再起動後にも残るかを確認してください。小さなファイルのパフォーマンスに関する問題については、アプリケーション状態のストレージ境界によって、応答性の問題と単純な容量不足を区別できます。