Jellyfinのエラーがクライアントとサーバーのどちらに起因するかを見分ける方法

Jellyfinのエラーは、操作用クライアントが正常に動作する一方で1台のデバイスだけが失敗する場合はクライアントに起因することが多く、同じメディア経路で複数のクライアントが失敗する場合はサーバーに起因することが多くなります。コーデックやハードウェアを変更する前に、ローカルの操作用クライアントでテストを始めてください。

サーバー、アカウント、メディア、画質を固定したまま、問題のあるクライアントと既知の正常なクライアントを比較し、さらにローカルでの直接再生とリモートまたはプロキシ経由の経路を比較します。その結果から、クライアントの対応能力、Jellyfinのトランスコード設定、ネットワーク経路のどれを変更すべきか、また証拠が混在しているため調査を止めるべきタイミングが分かります。

同じサーバーの操作用クライアントを使う

1台のクライアントで再生エラーが報告されています。まずは影響の少ない確認から始めます。同じアカウントと画質で、同じ項目を操作用クライアントで再生します。同じサーバーでの操作用クライアントテスト

重要なのは、具体的な結果です。操作用クライアントでは成功する、両方で失敗する、操作用クライアントでは別の再生モードが選択される、といった結果を確認します。別の変数を変更する前に、結果を記録してください。

推測ではなく、分岐結果を解釈します。問題のあるクライアントだけが失敗する場合はクライアント側の可能性が高く、両方が失敗する場合はサーバーまたは経路を調べます。再生モードが異なる場合は、まずコーデックと字幕の経路を比較してください。

再生モードとサーバーログを確認する

操作用クライアントでも失敗するか、同じサーバー経路が要求されています。まずは影響の少ない確認から始めます。影響を受けたセッションと操作用セッションについて、ダッシュボードの再生モードと対応するFFmpegまたはサーバーログの項目を比較します。

重要なのは、具体的な結果です。両方でダイレクト再生に失敗する、両方でトランスコードが終了する、片方のクライアントだけがトランスコードする、といった結果を確認します。別の変数を変更する前に、結果を記録してください。FFmpegログの証拠

推測ではなく、分岐結果を解釈します。両方のセッションで同じサーバーエラーが発生する場合はサーバー側の可能性が高く、片方だけがトランスコードする場合はクライアントの対応能力を再確認します。ログが正常な場合は、経路とブラウザーの状態をテストしてください。

ローカルへの直接経路とリモート経路を比較する

クライアントとサーバーのどちらが原因かは、まだ断定できません。まずは影響の少ない確認から始めます。同じクライアントとメディアを使い、LANのURL、次にリモートまたはプロキシ経由のURLで再生します。

重要なのは、具体的な結果です。ローカルでは成功してリモートでは失敗する、両方で失敗する、リモートでは成功してローカルでは失敗する、といった結果を確認します。別の変数を変更する前に、結果を記録してください。ローカル経路とリモート経路の比較

推測ではなく、分岐結果を解釈します。リモートだけが失敗する場合は、問題をプロキシ、DNS、ルーティング、帯域幅の範囲に絞ります。両方が失敗する場合は、サーバーの証拠を再確認してください。ローカルだけが失敗する場合は、バインド設定またはローカルDNSを調べます。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

最初のきっかけを再確認し、原因の担当範囲で止める

原因の担当範囲は条件付きで判断します。まずは影響の少ない確認から始めます。対象を絞った変更を1つだけ適用し、元のセッションと操作用セッションを1回ずつ再生します。

重要なのは、具体的な結果です。元のセッションは成功し、操作用セッションは安定したまま、元のセッションは引き続き失敗する、両方の経路が変化する、といった結果を確認します。別の変数を変更する前に、結果を記録してください。

推測ではなく、分岐結果を解釈します。元のセッションが成功し、操作用セッションも安定している場合は、そこで止めます。引き続き失敗する場合は変更を元に戻し、割り当てられた原因の担当範囲でエスカレーションしてください。両方が変化した場合は、最初に管理されていなかった変数まで戻って確認します。