Jellyfinが1人のユーザーまたは1台のデバイスでのみ失敗する場合、最初からサーバー全体を変更しないでください。影響を受けているアカウントを正常なデバイスでテストし、正常なアカウントを影響を受けているデバイスでテストして、相互に検証します。
この2つのテストで、シンプルな診断マトリックスを作成できます。問題がアカウントについて回る場合は、ユーザー権限とセッション状態を確認します。デバイスについて回る場合は、保存されたサーバーアドレス、アプリの状態、コーデックの経路、DNS、ネットワーク経路を確認します。アカウントに関係なく特定のメディア項目についてのみ発生する場合は、ユーザーやデバイスを原因と見なすのではなく、再生互換性を確認します。
2×2のアカウント・デバイステストを実行する
同じサーバーを使用し、可能であれば同じメディア項目を使います。まず影響を受けているユーザーを正常なデバイスでテストし、次に正常なユーザーを影響を受けているデバイスでテストします。症状がどちらに付随するかが分かるまで、パスワードの変更、アプリの再インストール、キャッシュの消去は避けてください。
1台のデバイスで両方のユーザーが失敗する場合は、デバイスまたはそのネットワーク経路が有力な分岐になります。1人のユーザーが複数のデバイスで失敗する場合は、アカウントが有力な分岐になります。1つのユーザーとデバイスの組み合わせでのみ失敗する場合は、サーバー全体の障害よりも、キャッシュされたセッション状態やクライアント固有の設定である可能性が高くなります。
ログイン拒否、ライブラリが表示されない、再生が拒否される、ストリームがバッファリングする、サーバーに到達できないなど、正確な失敗内容を記録します。「Jellyfinが失敗する」だけでは範囲が広すぎて修復できません。観測できる結果ごとに、次に確認すべき項目が異なります。
問題がユーザーについて回る場合は、権限とリモートアクセスを確認する
影響を受けているJellyfinユーザーを開き、正常なアカウントと、ライブラリへのアクセス、メディア再生権限、トランスコード権限、リモート接続権限を比較します。確認できた相違点を、一度に1つだけ変更してください。
Jellyfinのドキュメントでは、メディアの再生やトランスコードが必要な再生を許可するかどうかなど、ユーザーレベルの再生制御について説明しています。Jellyfinのユーザー再生権限
ユーザーがLAN上では動作するのにリモートでは動作しない場合は、認証情報をリセットする前に、そのアカウントのリモートアクセス権限とサーバーのネットワーク分類を確認します。リモートのみの拒否は、認証失敗ではなく、正しいポリシーによるものかもしれません。
問題がデバイスについて回る場合は、クライアント状態だけをリセットする
まず、スキーム、ホスト名、ポート、リバースプロキシのサブパスを含め、保存されたサーバーアドレスを確認します。正常なクライアントと文字単位で比較してください。古い直接IPアドレスや不足しているサブパスによって、サーバーが正常でも1台のデバイスだけが失敗することがあります。
アドレスが正しい場合は、アプリデータをすべて消去する前に、いったんサインアウトしてから再度サインインします。その後、クライアントが極端に古い場合は更新します。より限定的な手順で解決しなかった場合にのみ再インストールしてください。すべてを消去すると、セッショントークンや保存されたサーバーエントリが問題の原因だったかどうかを示す手がかりが失われます。
リモートデバイスでは、Jellyfinのリモートアクセス経路を使うと、意図したホスト名またはトンネル経路と、問題のクライアントに保存されているアドレスを比較できます。
ログインできるのに再生できない場合は、再生経路を比較する
正常なデバイスと問題のデバイスで同じファイルを再生し、Jellyfinのダッシュボードを確認します。それぞれのクライアントがダイレクト再生、リマックス、ダイレクトストリーム、トランスコードのどれを使用しているか、また字幕が有効になっているかを記録します。
Jellyfinのコーデックに関するドキュメントでは、サポートされていないコンテナ、音声、映像、字幕によって、クライアントごとに異なる変換経路が強制される可能性が説明されています。クライアントのコーデック互換性 そのため、デスクトップクライアントでは問題なく再生できるタイトルが、あるテレビでは失敗することがあります。
問題のデバイスだけでトランスコードが発生する場合は、メディアファイルを変更する前に、FFmpegのログとユーザーのトランスコード権限を確認します。両方のクライアントが同じ再生モードを使用しているのに一方だけが失敗する場合は、デバイスのネットワークとアプリの状態を引き続き確認します。
問題のデバイスだけでDNSとネットワーク経路を確認する
再生エラーではなくサーバーに到達できない場合は、同じネットワーク上の正常なデバイスと、問題のデバイスでDNS解決と経路を比較します。まず意図したホスト名をテストしてください。TLSやリバースプロキシのルーティングがホスト名に依存している場合、直接IPが同等だとは限りません。
Jellyfinのトラブルシューティングガイドでは、一致するWebトラフィックのログがまったくない場合、通常はリクエストがサーバーに到達していないことを示すと説明されています。ネットワークトラブルシューティングの手がかり
問題のデバイスからサーバーログにエントリが生成されない場合は、クライアント側でDNS、Wi-Fi/VLANの到達性、VPNの状態、証明書の信頼、保存されたアドレスを修正します。Jellyfinがリクエストを記録してアプリケーションエラーを返す場合は、マトリックスを上に戻り、アカウントまたは再生の挙動を確認します。
元のユーザー、デバイス、メディアで修正を検証する
特定した層を変更した後は、元の組み合わせに戻し、失敗した操作を再現します。別のノートパソコンで管理者アカウントが動作しても、テレビで利用している影響を受けた家庭内ユーザーが修復されたことの証明にはなりません。
その後、クライアントを一度再起動または再接続し、新しいセッションでも正常な状態が維持されることを確認します。リモートアクセスを修復した場合は、デバイスがまだLAN上にあるときだけでなく、外部ネットワークからも再テストしてください。
元のアカウントとデバイスの組み合わせで正常に動作し、制御の組み合わせも通常どおりであれば終了します。同じ限定的な失敗が残る場合は、マトリックスの結果、クライアントのバージョン、サーバーのバージョン、サーバーURL、再生モード、関連するログ抜粋を添えてエスカレーションしてください。
サポートとヒント
もっと読む

Jellyfinでは共有アカウントを1つ使うべきか、それとも家庭内で別々のアカウントを使うべきか?
必要な本人確認、アクセス、ペアレンタルコントロール、復旧の境界に応じて、Jellyfinの家庭用アカウントを選択してください。

作業完了後もJellyfinのメモリ使用量が高いままなのはなぜですか?
Jellyfinプロセスの増加とLinuxキャッシュを切り分け、メモリ使用量が増え続けるか、実際にメモリ圧迫が発生した場合にのみ調査してください。

Jellyfinのストレージ構成が復旧リスクになりつつある兆候
Jellyfinのストレージの役割を監査し、稼働中の状態をバックアップや再構築可能なデータから分離したうえで、復元によってその構成を検証する。

