iOS 原生 AVPlayer 無法播 AC3-in-fMP4,關閉「原生播放器」即解; 伺服器無誤。附查證:硬解未啟用(/dev/dri 權限不影響)、 repo.jellyfin.org 為開機暫時性失敗已恢復。 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
2.9 KiB
2.9 KiB
CT124 Jellyfin 播放失敗 — AVFoundation -11850
日期:2026-06-22 | 主機:CT124(192.168.42.124,Ubuntu 24.04 LXC) 服務:Jellyfin(
/opt/jellyfin,host network,jellyfin/jellyfinimage) 結果:伺服器無誤,根因在 client;關掉「原生播放器」即解。
一、症狀
iOS 官方 Jellyfin app 播放《死侍2 (2018)》跳錯誤對話框:
The server is not correctly configured. - The AVPlayerItem instance has
failed with the error code -11850 and domain "AVFoundationErrorDomain".
訊息雖寫「server is not correctly configured」,但這是 client 端 AVPlayer 丟的錯,不是伺服器設定問題。
二、根因
-11850 = AVErrorServerIncorrectlyConfigured,由 iOS AVPlayer(app 裡「使用原生影片播放器(測試版)」開關)丟出。
依賴鏈:
原生播放器(AVPlayer) → client device profile 宣稱 AC3 可直接播
→ 伺服器只做 remux(audio copy)塞進 fragmented MP4
→ AVPlayer 無法播 fMP4 容器內的 AC3 → -11850
證據(都在 CT124 上查得):
ffprobe "/movies/死侍2 (2018).mkv"→ 視訊 h264 High(相容)、音訊 ac3 5.1。docker logs jellyfin裡那條 transcode 指令是純 remux,音軌被 copy 而非轉碼:ffmpeg ... -i file:"/movies/死侍2 (2018).mkv" -codec:v:0 copy ... \ -codec:a:0 copy -f mp4 -movflags frag_keyframe+empty_moov+delay_moov ...- client 收到後放棄,伺服器約 15 秒後
Killing transcoding/FFmpeg exited with code 0。 - 容器
Up (healthy)、ffmpeg 7.1.2、硬解全在 → 伺服器本身正常。
三、修法
關掉 iOS Jellyfin app →「設定 → 播放 →『使用原生影片播放器(測試版)』」。
關掉後改用內建 web 播放器,AC3 正常播放。/opt/jellyfin 不需任何更動。
「優先在 HLS 中使用 fMP4」可保持開啟,與此錯誤無關。
四、備查(本次發現、與此錯誤無關;已查證,現階段皆無需處理)
硬解轉碼目前未啟用 → /dev/dri 權限不影響
encoding.xml:<HardwareAccelerationType>none</HardwareAccelerationType>,Jellyfin 現為純軟解/remux,沒用 GPU。/dev/dri(card0、renderD128)在 CT124 內已是nobody:nogroup(65534)、crw-rw----,container 內 root(userns 映射)也NO-ACCESS。- 根因:CT124 是非特權 LXC,PVE host 的 render gid(993)未映射進 userns,故裝置顯示為 nobody、容器碰不到。
- 真要啟用硬解(VAAPI/QSV)需動 PVE host
/etc/pve/lxc/124.conf(lxc.idmap或 PVE 8.2 device passthrough 指定 gid)+ 重啟 LXC + Jellyfin 設定改vaapi/qsv。屬獨立工程,等軟轉 CPU 撐不住再做。
repo.jellyfin.org:443 抓不到 → 暫時性,已恢復
- 啟動 log
Resource temporarily unavailable發生在 07:53 開機當下,網路/egress 未起齊。 - 現況:host 與 container 皆
HTTP 302~0.6s(走 IPv6),已恢復,無需處理。