通常、1台のテレビだけで再生に失敗するのは、そのテレビのアプリ、デコーダー、ネットワーク経路、またはクライアントプロファイルが、正常に動作するデバイスと異なるためです。
ブラウザー、スマートフォン、または別のテレビで同じライブラリを再生できる場合、メディアサーバーやストレージに問題がないと即断はできませんが、再生に失敗するクライアントが最も有力な切り分け要素になります。再生の判定、コーデック対応、音声と字幕の処理、接続の分類、アプリのバージョン、キャッシュされた状態、そのテレビからのリクエストによって生成されたサーバーログを比較するため、一度に1つのファイル、1つのアカウント、1つのネットワークだけを使用してください。
同じファイルとアカウントで問題を再現する
再生に失敗するテレビと正常なクライアントで、同じユーザー、画質設定、音声トラック、字幕トラック、再生位置を使って、影響を受けるタイトルを1つ再生します。正確なエラー発生時刻と、ポスター、音声、または最初の映像フレームが表示されるかどうかを記録してください。
Jellyfin Tizenの報告では、あるSamsung製テレビでは再生に失敗した一方、同じメディアが別のテレビ、Androidクライアント、その他のデバイスでは正常に再生されました。決め手となったのは、1台のテレビクライアントに問題が限定されていたことです。
すべてのクライアントで同じファイルの再生に失敗する場合は、元ファイルの破損、権限、またはサーバー処理を再確認してください。多くのファイルで1台のテレビだけが失敗する場合は、そのテレビのアプリビルド、再生プロファイル、デコーダー、ネットワーク経路を優先して確認します。
再生判定と失敗理由を比較する
各クライアントが再生を開始するときに、メディアサーバーのダッシュボードを開きます。ダイレクト再生、ダイレクトストリーム、またはトランスコードのいずれか、選択された映像・音声コーデック、字幕方式、ビットレート、クライアントプロファイルに関する理由を記録してください。
Tizenの再生問題では、メディアがクライアントでサポートされていないという明確なメッセージが報告されています。これは、サーバーの処理能力が問題になる前に、クライアントの対応能力のネゴシエーションによって再生が阻止される可能性を示しています。
テレビがダイレクト再生を要求してすぐに失敗する場合は、診断として画質を1段階下げてみます。トランスコードで成功するなら、テレビのコーデックプロファイルを確認してください。両方の経路で失敗する場合は、配信コンテナ、サーバーログ、アプリの状態、ネットワークリクエストを調べます。
映像、音声、コンテナ、字幕の互換性を切り分ける
まず、H.264映像とステレオAAC音声を含むMP4形式の、確実に再生できるファイルをテストします。その後、1回につき1つの要素だけを変更してください。元の映像に互換性のある音声トラックを組み合わせ、字幕を無効にし、プレーンテキスト形式の字幕トラックを試します。
クライアントがHEVC映像に対応していても、特定のプロファイル、レベル、色深度、Dolby Visionモード、音声コーデック、チャンネル構成、字幕形式には対応していない場合があります。Jellyfin Tizenのディスカッションでは、映像のトランスコードが利用できない状況で、非対応の映像コーデックプロファイルが再生失敗の原因として関連付けられています。
再生を復旧させた最初の変更を基準に、対策を選びます。互換性のあるトラックを選択する、対応するトランスコードを許可する、より高機能なクライアントを使用する、または副変換版を用意してください。原因が分類されていない1件の失敗だけを根拠に、ライブラリ全体を再エンコードしないでください。
テレビが異なるネットワーク経路を使用していないか確認する
テレビが使用しているサーバーアドレスを、正常なクライアントと比較します。ローカルIPとパブリックホスト名、直接アクセスとリレー経由、リバースプロキシの使用状況、DNSの結果、TLS証明書、サーバーがテレビをローカルまたはリモートとして分類しているかを確認してください。
ブラウジングやログインが正常でも、クライアント固有のプロキシ処理によって再生が壊れることがあります。Jellyfin Tizenの問題では、LANアドレス経由ではファイルを再生できた一方、リバースプロキシ経路では失敗しました。
切り分けのため、テレビからサーバーの直接的なローカルアドレスだけを使用してテストします。それで動作する場合は、安全でないバイパスを恒久的な接続先にするのではなく、プロキシヘッダー、WebSocketまたはストリーミング経路、TLS、ホスト名の分類を修正してください。
テレビの実際の有線またはWi-Fi接続を測定する
テレビでネゴシエートされたリンク速度、Wi-Fi帯域、信号品質、パケット損失、スイッチまたはアクセスポイントのカウンターを確認します。ホームサーバーが2.5GbEを使用していても、多くのスマートテレビのイーサネットは100Mbpsです。
既知の正常な有線経路と、対応している場合は安定した5GHzまたは6GHz Wi-Fiの両方でテレビをテストします。テレビのそばに置いたノートパソコンでネットワーク速度を測定しても、テレビ自身のアダプターが同じスループットを得ていることの証明にはなりません。
ビットレートを下げるだけでタイトルを再生できるようになる場合は、ファイルの再生時ピーク値とテレビの経路を比較します。低ビットレートでも失敗し、継続的な通信が始まる前に問題が発生する場合は、コーデック、アプリ、またはプロファイルの診断に戻ってください。
クライアントの状態をリセットし、アプリのバージョンを比較する
テレビのモデル、オペレーティングシステムのバージョン、メディアアプリのバージョン、サーバーのバージョン、該当する場合はWebバンドルのバージョン、インストール方法を記録します。両方のデバイスが同じクライアントを実行していると決めつけず、正常なテレビと比較してください。
古いWebデータやアプリのキャッシュが原因で、特定のファイルの再生時に1台のクライアントだけが停止することがあります。Jellyfin Tizenの報告では、テレビのブラウザーに保存されたデータを消去することで再生が復旧しました。
サインアウトし、アプリのキャッシュまたは閲覧データだけを消去して、テレビを完全に再起動します。その後、対応している方法で再インストールまたは更新してください。リセット前のサーバーログは保存しておきます。そうしないと、一時的なクライアントのクリーンアップによって、再現可能な唯一の手掛かりが消える可能性があります。
テレビが要求した場合にのみハードウェアトランスコードを確認する
再生に失敗するテレビだけが映像変換をトリガーする場合は、GPUのデコード、フィルタリング、エンコードの動作と、正確なFFmpegエラーを確認します。ダイレクト再生が正常なクライアントがあっても、サーバーがテレビの非対応形式をトランスコードできるとは限りません。
ハードウェアトランスコードの確認に関するZimaSpaceの手順は、クライアント互換性による要求と、GPUまたはコンテナのデバイス経路の障害を切り分けるのに役立ちます。
GPUを疑う前に、字幕を無効にし、互換性のある音声トラックで再テストします。単純なH.264トランスコードは成功するのに、HDRトーンマッピングや字幕の焼き込みで失敗する場合は、ハードウェアアクセラレーションが利用できないと判断するのではなく、特定のフィルターステージを分類してください。
テレビの実際の再生ワークフロー全体で修正を確認する
原因に合った最小限の変更を適用した後、起動、シーク、一時停止、再開、チャプタージャンプ、別の音声、字幕、および似たコーデックを使用する2つ目のタイトルをテストします。各操作中にサーバーログを監視してください。
ZimaSpaceのホームメディアサーバーのチェックリストでは、デバイスによってコーデック、字幕、アプリの動作が異なる可能性があるため、複数種類のクライアントでテストすることを推奨しています。
問題が解決したといえるのは、再生に失敗していたテレビが予測可能な再生経路を使用し、サーバーにクライアント固有のエラーが繰り返し記録されず、テレビの電源再投入とアプリの再起動後も結果が維持される場合です。今後のクライアント更新に備え、正常に再生できるテストファイルを基準として保管してください。
サポートとヒント
もっと読む

Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか?
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。

Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか?
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。

リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか?
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。

