あるZimaOSユーザーは、テストしたすべてのデバイスで、映画とMP3ファイルの再生時に「このクライアントではメディアがサポートされていないため、再生に失敗しました」というJellyfinのメッセージを確認しました。このメッセージがメディアのサポートに言及していたため、当初はブラウザーキャッシュ、コーデック、トランスコード、権限などが原因として疑われました。
ログは別の状況を示していました。Jellyfinは正常に起動し、FFmpegを検出し、複数の音声・動画デコーダーを利用可能にし、グラフィックデバイスの権限も正常であると報告していました。再生を開始すると、サーバーはファイルが見つかりませんというメッセージを繰り返し記録しました。コミュニティメンバーのgelbuildingは、このメッセージの原因を、Musicディレクトリだけを/MediaにマウントするDockerボリュームパスに突き止めました。一方、Jellyfinのライブラリは依然として/Media/Music、/Media/Movies、/Media/TV Shows以下のファイルを想定していました。
すべてのクライアントに表示された再生エラー
MrPenguinによると、以前のサポート対応後もJellyfinとユーザーのDNS設定は安定していました。バックアップも作成済みでした。新たな障害はどのデバイスからでも映画と音楽の両方に影響したため、原因がキャッシュ、コーデックのサポート、ファイル権限のいずれなのかを確認するのは妥当でした。
ハードウェアの制限とストレージパスの障害を切り分けたいユーザーは、Jellyfinのハードウェア要件を参照できます。ただし今回、決定的な証拠となったのはクライアントのメッセージではなく、ファイルが見つからないことを示す行でした。
ログが示していたのは非対応コーデックではなく、ファイルの欠落でした
起動ログから、x64版LinuxServer.ioコンテナ内のUbuntu 24.04.3 LTSでJellyfin 10.10.7が動作していることが確認できました。また、Jellyfin FFmpeg 7.1.2、多数の利用可能なデコーダーとエンコーダー、CUDA、VA-API、QSV、DRM、OpenCL、Vulkanなどのハードウェアアクセラレーションインターフェースも確認されました。
グラフィックデバイスのチェックも問題ありませんでした。
/dev/dri/renderD128 の権限は正常です
/dev/dri/card0 の権限は正常ですその後、再生リクエストによって診断を変える決定的な行が出力されました。
ファイル '/Media/Music/Beyonce/Unknown Album/Single Ladies ... .mp3' が見つかりません不足していた Folder.jpg パスも表示されました。つまり、Jellyfinのデータベースには、現在のコンテナ内に存在しないライブラリパスがまだ参照されていたのです。サーバーがソースファイルをまったく開けない場合、コーデックの互換性では解決できません。
公式のJellyfinトラブルシューティングガイドでも、クライアントに表示されたメッセージだけに頼らず、サーバーとFFmpegのログから再生の診断を始めることが推奨されています。
Commands Used to Check the Container Paths
コンテナ内のパスを確認するために使用したコマンド
Gelbuildingは、実行中のJellyfinコンテナから実際に何が見えるかを確認するよう投稿者に求めました。
docker exec -it jellyfin ls -lah /Media
docker exec -it jellyfin ls -lah "/Media/Music" | docker exec -it jellyfin ls -lah "/Media/Music/Beyonce/Unknown Album"先頭
返信では、アクティブなDockerマウントも要求しました。 | docker inspect jellyfin --format '{{json .Mounts}}'sed 's/},/},\n/g'
これらの確認では、異なる2つの問いに答えています。docker execコマンドはJellyfinの視点からパスが存在するかどうかを示し、docker inspectはどのホストディレクトリがコンテナにマッピングされているかを示します。公式のJellyfinコンテナドキュメントでは、永続的な設定とメディアボリュームのマッピングについて詳しく説明されています。
実際のボリュームマッピングの問題
投稿者の確認結果には、次のメディアマッピングが示されていました。
ホスト: /media/2 TB Master Drive/Media/Musicコンテナ: /Media のフォルダーではなく このマッピングにより、ホストの /Mediaコンテナパスの直下にフォルダーを作成します。 /Media/Music は作成しません。 /Media.
コンテナ内。したがって一覧にはアーティストフォルダーが直下に表示されました。
同時に、Jellyfinは次のように始まるパスを開こうとしていました。/Media/Music/.../Media/Movies/...
/Media/TV Shows/...
/MediaZimaOSのアプリ設定では、Musicサブフォルダーが直接Mediaにマッピングされているその一方で、Jellyfinはそのコンテナディレクトリの下に、Music、Movies、TV Showsを個別のパスとして想定していました。
コミュニティが提案したマッピング変更 Media Gelbuildingは親フォルダーのマウントを推奨しました。 のフォルダーではなく サブフォルダー：
次から変更：
/media/2 TB Master Drive/Media/Music → /Media
次のように変更します。
/media/2 TB Master Drive/Media → /Media親フォルダーをマウントすると、コンテナには次のように公開できます。 /Media/Music, /Media/Moviesにスペースが1つ欠けているだけでも、 /Media/TV Shows Jellyfinにすでに保存されているパスを使用します。スペースと大文字・小文字は完全に一致している必要があり、たとえば テレビ番組 パスを変更します。
修正したボリュームマッピングを保存した後、返信ではJellyfinを再起動し、ダッシュボード → ライブラリ → すべてのライブラリをスキャンを実行するよう投稿者に案内しました。公式のJellyfinライブラリガイドでは、サーバーダッシュボードでライブラリを管理する場所が説明されています。
アプリケーションを変更または再構築する前に、既存の設定バックアップを保持してください。メンテナンス前の Jellyfin バックアップに関する Shop の記事では、アプリケーションの状態とメディアライブラリを別々の復旧対象として扱うべき理由を説明しています。
その他のログ行は、再生失敗の確認済みの原因ではありません
ログには、次のアドレスへの NextPVR 接続拒否も含まれていました： localhost:8866 および静的な WebRootPath 警告も含まれていました。これらの項目は Live TV やウェブアセットについて個別に注意が必要かもしれませんが、失敗した MP3 リクエストは明示的なファイル未検出エラーで終了していました。スレッドでは、NextPVR の障害と音楽・映画ファイルの欠落は関連付けられていませんでした。
同様に、これはハードウェアトランスコーディングが壊れていたことを示す証拠でもありません。ログには FFmpeg と複数のコーデックが利用可能であることが示されていました。実際にトランスコーディングが問題になるケースでは、ZimaOS のハードウェアアクセラレーションストリーミングガイドが参考になりますが、アクセラレーション設定を変更しても、誤った Docker マウントは修復できません。
スレッドで確認されたことと、確認されなかったこと
ログの証拠と Docker の検査結果から、パスマッピングの不一致が強く示されており、最後の返信では正確に修正されたマッピングが提示されました。ただし、スレッドは MrPenguin が変更を適用した後の最終的な再生テストを投稿する前に終了しています。そのため、このページではマッピングの修正を、元の投稿者が成功を確認したものではなく、コミュニティの証拠に基づく解決策として説明する必要があります。
Jellyfin の再生と Docker パスに関する FAQ
ファイルが存在しないのに、なぜ Jellyfin はメディアがサポートされていないと言ったのですか？
クライアントには一般的な再生エラーが表示されました。サーバーログには具体的な原因が示されていました。Jellyfin は、データベースに保存されたライブラリパスでソースファイルを見つけられなかったのです。
FFmpeg を再インストールしたり、コーデックを変更したりすれば、このケースは解決しますか？
いいえ。ログには Jellyfin の FFmpeg と多数のデコーダーおよびエンコーダーがすでに表示されていました。コーデックは、コンテナ内のパスに存在しないソースファイルを処理できません。
Jellyfin が再生できなくなったライブラリ項目を表示できたのはなぜですか？
Jellyfin は、マウントが変更された後もスキャン済みのメタデータをデータベースに保持することがあります。項目は表示されたままですが、Jellyfin が以前のファイルシステムパスを開こうとすると、再生に失敗します。
親の Media フォルダーをマウントすべきですか？
このスレッドに示されたフォルダー構成であれば、はい。ホスト側の親 Media ディレクトリからコンテナ内のパスへのマッピング /Media 既存のライブラリが想定する Music、Movies、TV Shows のサブディレクトリを維持します。
元の投稿者は、その後再生できたことを確認しましたか？
表示されているスレッド内に、最終確認はありません。最後の返信では、不一致を指摘し、修正後のマッピングと再スキャンの手順が示されています。
