クライアントによってPlexの応答性が異なるのはなぜですか？
同じサーバーを使っていても、Plex の反応がクライアントごとに異なるのは、各アプリが独自の再生エンジン、キャッシュ動作、互換性の制限、ネットワーク経路を追加するためです。
反応の速さは、単純なストリームのビットレートだけで決まるものではありません。ユーザーが気づくのは、ライブラリの閲覧、ポスターの読み込み、最初のフレームが表示されるまでの時間、シーク、字幕の変更、トラックの切り替えなどであり、これらの操作はシステムの異なる部分に影響します。適切に診断するには、メディアとサーバーを一定に保ち、どの遅延がクライアントに追随し、どの遅延がどの環境でも再現するのかを確認します。
クライアントのコーデック対応によって、Plex が行う処理は変わる
元の映像と音声をそのまま受け入れられるクライアントなら、軽い処理経路で再生を開始できます。一方、別のクライアントでは、リマックス、音声変換、または完全な映像トランスコードが必要になる場合があります。ユーザーにはアプリの動作が遅くなったように感じられますが、違いの原因はインターフェースの速度ではなく、互換性にあります。
クライアントのコーデック対応は、スマートフォン、タブレット、ストリーミングスティック、テレビ、接続されたオーディオ機器によって異なります。同じエンドポイントでも、別のファイルや選択したトラックによって動作が変わることがあるため、どのデバイスクラスでも常にダイレクト再生できるとは限りません。
同じソース、元の品質、音声トラック、字幕を使って、2つのクライアントを比較します。遅いクライアントだけが変換を開始するなら、サーバーハードウェアを評価する前に、再生経路によって反応速度が左右されています。
閲覧速度は、ローカルのUIキャッシュとメタデータキャッシュに左右される
ライブラリを開く処理は、映画を再生する処理と同じではありません。クライアントはメタデータ、ポスター、コレクション、状態情報を取得し、その後に独自のインターフェースを描画します。そのため、ローカルキャッシュの状態、アプリのバージョン、画像のデコード、デバイスのストレージによって、動画の配信自体が正常でも、特定のインターフェースだけが遅く感じられることがあります。
Plex のクライアントは、時間の経過とともに各プラットフォームで書き換えや統合が行われてきました。つまり、クライアントの実装は、サーバーのスループットとは別に変化する可能性があります。アクティブなストリームが正常なのにナビゲーションが遅い場合は、サーバーハードウェアを変更する前に、UIの反応速度とメディア配信を切り分けてください。
各クライアントで、起動直後と2回目の起動を試し、既知のストリームをすでに再生している状態で閲覧速度を比較します。ローカルキャッシュが温まると大幅に改善するクライアントは、すべてのデバイスに対してメタデータをゆっくり返すサーバーとは別の問題です。
音声や字幕の選択によって、起動やシークの速度が変わることがある
選択したトラックは再生プランに影響します。クライアントが対応していない音声形式や、合成が必要な字幕モードを要求すると、それまではダイレクト再生できていた動画でも、Plex が変換処理を追加してバッファーを再構築することがあります。トラックの切り替えによって、この処理の一部が繰り返される場合もあります。
クライアントが字幕を直接処理できない場合、選択した字幕によって、互換性のある再生経路が変わることがあります。そのため、Plex の字幕の互換性ルールは、クライアントの反応速度を左右する要素です。すべての字幕が同じ動作を引き起こすと考える理由にはなりません。
字幕をオフにし、幅広く対応されている音声トラックを使って、同じシークと起動の手順を繰り返します。特定のエンドポイントでのみ反応が正常化するなら、サーバー全体のCPUスコアよりも、クライアントとメディアの相互作用のほうが有益な情報になります。
再生エンジンが異なると、同じファイルでも処理が変わることがある
Plex のクライアントがすべて同じメディアフレームワークを使っているわけではありません。サードパーティ製プレーヤーなら、別のアプリがリマックスやトランスコードを行う形式でも再生できる場合があります。また、ブラウザーは、テレビ向けのネイティブアプリとは異なるコーデックやコンテナの制約を受けることがあります。そのため、設定を変更しなくても、同じサーバーから異なる経路で配信される可能性があります。
再生エンジンを変更すると、サーバーを変更しなくても互換性やバッファリングの動作が変わることがあります。たとえば Infuse は、帯域幅や再生条件に応じて最適化されたPlexストリームを要求できます。そのため、エンドポイントのソフトウェアもメディア経路の一部として診断に含める必要があります。
可能であれば、同じデバイスで別の再生クライアントやブラウザーを試します。ハードウェアやネットワークではなくアプリに遅延が追随するなら、診断の対象をクライアント層に絞ってください。
クライアント間の時間を比較して、体感とサーバー遅延を切り分ける
同じタイトルについて、ライブラリを開く時間、再生開始までの時間、シークから復帰するまでの時間、音声または字幕を切り替える時間の4項目を計測します。同じLAN上で2〜3台のクライアントを使って実行し、その後、1台のクライアントでリモート接続して繰り返します。これにより、遅い段階がデバイス、ネットワーク経路、サーバーのどれに追随しているかがわかります。
クライアントによって異なる起動遅延は、異なるエンドポイントでも同じ時間の問題が再現するまでは、1つのサーバー障害として判断するには範囲が広すぎます。ストレージ、CPU、データベースの設定を変更する前に、同じファイル、トラック、ネットワーク条件で比較してください。
リモート再生で起動やシークに差がある場合は、キーフレーム間隔とリモート起動も検証すべき時間要因になります。クライアント、ローカルキャッシュ、再生エンジンを変更しても遅延が残る場合にのみ、Plexサーバーの反応速度を原因と判断してください。
おすすめ商品
テック＆AIハブ
もっと読む
Plexの状態とは何か、どの部分を永続化する必要があるのか？
永続的なPlexの状態情報とは、再起動や再構築後もサーバー環境を維持する情報を指します。メディアデータと一時的なトランスコードデータは、それぞれ別の役割を担います。
Plexはローカルセッションとリモートセッションで認証をどのように処理しますか？
Plexの認証はサーバーとアカウントの識別から始まり、その後、ローカルまたはリモートのネットワーク経路によって到達可能性と安全な接続の動作が決まります。
ライブラリデータが増えると、Plexの検索が遅くなるのはなぜですか？
ライブラリの増加だけが原因とは限りません。データベースのサイズを問題視する前に、クエリの形状、インデックス、キャッシュの状態、ストレージのレイテンシ、書き込みアクティビティを確認してください。
