Embyで「Playback Error: No compatible streams are currently available」が出たときの原因と解決策（Unraid Docker環境）

EmbyをUnraidのDockerで運用していると、ある日突然「Playback Error: No compatible streams are currently available（互換性のあるストリームがありません）」と表示され、どの動画も再生できなくなることがあります。以前は問題なく再生できていたのに、アップデート後から一斉に発生するケースも珍しくありません。

Embyで「Playback Error: No compatible streams are currently available」が出たときの原因と解決策（Unraid Docker環境）

「No compatible streams」が意味すること

このエラーは、単純に「ファイルが壊れている」というよりも、Embyが再生に必要な方式（直再生・直接ストリーム・トランスコード）を成立させられないときに出やすい症状です。
特にUnraidのDocker環境では、トランスコード担当のffmpegが正常に動いていない、あるいはコンテナからメディアへアクセスできていないといった“環境起因”で全滅しがちです。

ログに ffmpeg-transcode ... があり、さらに HTTP 500 が見えている場合は、再生リクエスト自体は来ているのに、内部処理（多くはトランスコード開始）が失敗してサーバ側エラーになっている可能性が高いです。

まず疑うべき原因トップ5（Unraid Docker）

1) パスのマッピング（Volume）がずれている

以前の設定やテンプレート変更、Unraid側の共有設定変更で、Embyコンテナ内から見えるメディアのパスが変わっていることがあります。

ライブラリ登録時のパスは正しいか（コンテナ内の /mnt/... ではなく、割り当てた /media などになっているか）
複数の共有や複数のマッピングが競合していないか（同じ共有を別名で割り当てて混乱している等）

対策
Dockerテンプレートの「Path」設定を見直し、Embyが参照するライブラリパスを統一します。ライブラリ側のパスもコンテナ基準で再設定し、必要ならライブラリスキャンを実行します。

2) 権限（Permissions）問題で読み取り・トランスコードができない

Unraidの共有フォルダ権限、DockerのPUID/PGID、umaskなどが変わると、ファイルは見えても読み取りできない／トランスコード用の一時書き込みができないことがあります。結果としてffmpegが開始できずエラーになりやすいです。

対策

Embyコンテナの PUID / PGID をUnraidの運用ユーザーに合わせる
メディア共有とトランスコードディレクトリの権限を確認（読み取りだけでなく“書き込み”も必要な場面がある）
Unraidの「New Permissions」系ツールで整合を取る（運用方針に合わせて実施）

3) トランスコードディレクトリの設定が死んでいる（容量不足・存在しない）

Embyはトランスコード時に一時ファイルを書きます。ここが

存在しない
書き込み不可
容量不足
キャッシュドライブのトラブル
だと、再生のたびに落ちます。

対策

Embyの「トランスコード」設定でパスを確認し、Unraid側で実体があるかチェック
推奨は高速ストレージ（cache）へ割り当て、コンテナにも適切にマッピング
ディスク残量を確認（意外とここが原因で全滅します）

4) ハードウェアアクセラレーション設定が崩れた

アップデート後に、GPUデバイスの割り当てやドライバ状況が変わり、ハードウェアトランスコードが失敗→再生不可になることがあります。特に「以前は快適だったのに突然」パターンで多いです。

対策

いったんEmby側でハードウェアアクセラレーションを無効化して再生テスト
NVIDIA/Intel iGPU利用なら、UnraidのプラグインやDockerデバイス割り当て（/dev/dri やNVIDIAランタイム）を再確認
直近でGPU関連の設定を触っていなくても、OS更新で前提が変わることがあります

5) ffmpegの実体・権限・互換性問題

Embyは内蔵ffmpegを使うことが多いですが、コンテナやイメージ更新で挙動が変わる場合があります。ログにffmpeg関連が出ているなら、ffmpegが起動できていない／コーデック初期化で落ちている可能性があります。

対策

Embyコンテナを最新安定版へ更新し、再起動
逆に「更新後に発生」なら、直前のバージョンへ一時ロールバックして切り分け
コンテナのヘルス、ログのエラー行（permission denied / no such file / invalid argument など）を重点的に確認

「HTTP 500」が示す切り分けポイント

HTTP 500は“サーバ内部エラー”なので、クライアント（テレビ、ブラウザ、アプリ）が悪いというより、Embyサーバ側の処理が失敗している合図です。切り分けは次の順が効率的です。

直再生できる軽いファイル（H.264/AACのMP4など）を選び、同じクライアントで再生
だめならクライアントを変えて再生（ブラウザや別端末）
それでも全滅なら、パス・権限・トランスコード先・ffmpegに絞り込み
一時的にトランスコード無効・HW無効で挙動が変わるか確認
ログの該当トランスコードジョブの直前直後にある具体的な失敗理由を確認

「どの動画も再生できない」場合、個別のコーデック問題よりも、**共通の土台（アクセス権、パス、トランスコード先、ffmpeg起動）**が壊れていることがほとんどです。

すぐ効く復旧アクション（手戻りが少ない順）

ここからは、環境を大きく変えずに試せる順番です。

A. Dockerコンテナの再起動＋イメージ更新

コンテナ再起動 → 改善することがある（残ったプロセスや一時ファイルの問題）
更新する場合は、更新前後で症状が変わったか必ずメモ

B. トランスコード先を「確実に書ける場所」へ変更

Unraidのcache上の専用フォルダを作り、権限を揃える
Emby設定のトランスコードパスをそこへ
コンテナへ同じパスをマッピング

C. ハードウェアアクセラレーションを一旦オフ

まず“再生できる状態”へ戻すのが優先
復旧後にGPU設定を詰める

D. ライブラリパスの再確認（コンテナ内視点）

Embyが見ているパスが、Dockerの割り当てと一致しているか
共有フォルダの場所を移動した／名前を変えた／マウント方式を変えた、があるとズレます

E. 権限の整合を取る

PUID/PGIDの見直し
メディアとトランスコード先の権限統一
変更後はコンテナ再起動

事故を防ぐ運用のコツ（再発予防）

トランスコード先は専用の固定フォルダにし、容量監視をする
メディア共有のパスはDocker内で /media のように単純化し、ライブラリもそれに統一
アップデート時は「Emby」「Unraid」「GPUプラグイン」を同時に大きく変えない（原因追跡が難しくなる）
何か変えたら、直再生できるテスト動画を1本決めておき、動作確認の基準にする

まとめ：このエラーは“動画”より“環境”を疑うのが近道

UnraidのDockerでEmbyが突然「No compatible streams」になり、ffmpegログにHTTP 500が見える場合は、トランスコードの開始失敗やコンテナからのアクセス不整合が主因になりやすいです。
特に「以前は問題なかったのに、更新後から全部だめ」は、パス・権限・トランスコード先・HWアクセラレーションのどれかが崩れている可能性が高いので、復旧アクションA〜Eの順に当てていくと、手戻り少なく原因へ近づけます。