複数のデバイスで同時にストリーミングすると、なぜPlexは断続的に失敗するのですか？
複数クライアントでPlexが断続的に失敗する場合、最初に変化するストリームがトランスコード、帯域幅、ストレージI/O、または特定クライアント固有の経路のどれなのかを確認すると、原因を診断しやすくなります。
1台のテレビでは安定しているサーバーでも、スマートフォン、リモートブラウザー、スマートTVが同時に別のファイルを再生し始めると、失敗することがあります。クライアントごとに要求する処理は同じとは限りません。1台はダイレクトプレイでも、別の1台ではビデオのトランスコードや字幕の焼き込みが必要になったり、WANを経由したりする場合があります。クライアントを1台ずつ追加して障害を再現し、制限やハードウェアを変更する前に、Plexダッシュボードで各セッションが実際に何をしているかを記録してください。
同時再生をテストする前に、1ストリームの基準値を作る
まず、最も頻繁に失敗するクライアントとファイルの組み合わせを使い、1ストリームだけを再生します。Plexがダイレクトプレイ、ダイレクトストリーム、トランスコードのどれとして報告しているかを記録し、CPU、GPU、ネットワーク、ディスクの動作を確認します。単独でもストリームが失敗する場合、主な原因は同時実行ではないため、以降のテストは中止してください。
Plexの説明では、トランスコードやリモート再生が関係する場合、サーバーのストリーミング容量は主に処理能力とネットワーク帯域幅によって制約されます。この違いは重要です。サーバーは多数のダイレクトプレイセッションを処理できても、複数のクライアントが変換を要求すると、すぐに限界へ達することがあります。
基準値のテストに問題がなければ、最初のクライアントを変更せずに2台目を追加します。最初に確認できる失敗が発生するまで、クライアントを1台ずつ追加してください。限界点で追加したストリームは、ランダムなエラーメッセージよりも有用です。どの新しい処理によってサーバーの状態が変化したのかが分かるためです。
ダッシュボードでトランスコードの負荷とネットワーク負荷を切り分ける
失敗が発生したら、ダッシュボードでアクティブなすべてのセッションを確認します。失敗したタイミングが新しいハードウェアトランスコードまたはソフトウェアトランスコードの開始と一致する場合は、同じクライアントでダイレクトプレイに対応したファイルを使うか、より単純な字幕処理でテストします。エラーが消えるなら、トランスコード処理が有力な原因です。
ZimaSpaceのハードウェアアクセラレーションガイドは、複数のストリームでCPUから利用可能なアクセラレーターへ処理を移せる理由や、サーバーが他のNAS処理のためにも余裕を必要とする理由を理解するのに役立ちます。ハードウェアアクセラレーションは、同時実行数に制限がないことの証明ではありません。確認すべきリソース経路の1つです。
ローカルセッションは正常なのにリモートストリームだけが失敗する場合は、同じ時間帯にサーバーの実際のアップロード帯域幅を測定し、合計ストリームの要求量と比較します。ローカルとリモートのクライアントが同時に失敗する場合は、インターネット接続を共通の原因と決めつけず、コンピュートまたはストレージの確認に進んでください。
失敗が発生する時点でコンテナまたはホストが飽和していないか確認する
ストリームを追加している間、Plexコンテナとホストを監視します。同じクライアント数でCPUの上限、GPUのビデオエンジンの飽和、メモリ圧迫、または高いI/O待ちが現れるなら、失敗後に確認した平均使用率よりも強い手がかりになります。最初に上限へ達するリソースを探してください。
Dockerのコンテナ統計コマンドを使うと、テスト実行中のコンテナのCPU、メモリ、ネットワーク、ブロックI/Oを確認できます。これをPlexのセッション表示と組み合わせれば、リソースの急増がPlexに属するものか、どのクライアントの操作が引き金になったのかを判断できます。
リソース使用量が少ないのに1台のクライアントだけが失敗する場合は、そのクライアントまたはメディアファイルだけを交換します。特定のデバイス、コーデック、字幕形式、またはネットワーク経路に伴って失敗するなら、より限定的なクライアント互換性の問題として扱います。1つのエンドポイントでしか再現しない問題を解決するために、サーバー全体の制限を下げないでください。
適合する最小限の修正を適用し、同じクライアント構成で再テストする
トランスコードの限界が確認された場合は、不要なトランスコードを減らし、ハードウェアアクセラレーションを確認するか、NASの応答性を維持できるよう同時トランスコード数の上限を意図的に設定します。アップロード帯域幅のボトルネックが確認された場合は、リモートストリームの画質を調整するか、利用可能な上り帯域幅を増やします。ストレージI/Oが原因の場合は、移動する前にメディアのパスと一時トランスコードのパスを分けてテストしてください。
最初に失敗したときとまったく同じクライアントの順序を再現し、以前の限界点を超えるまで十分な時間実行します。修正が成功したというのは、単一のテスト動画が再生を開始したということではありません。同じメディア形式、同じリモート／ローカル条件の下で、同じ台数と構成のクライアントが安定して動作することを意味します。
リソースとの相関がないまま失敗箇所が変化し続ける場合は、各クライアントの開始時刻と失敗時刻を記録したPlexサーバーログを収集します。クライアントのモデル、Plexアプリのバージョン、サーバーのバージョン、メディアの詳細、最初に失敗した同時実行ステップを添えてエスカレーションすれば、次の診断を再現可能な証拠から始められます。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
