# CT124 Jellyfin 播放失敗 — AVFoundation `-11850`

> 日期：2026-06-22　|　主機：CT124（192.168.42.124，Ubuntu 24.04 LXC）
> 服務：Jellyfin（`/opt/jellyfin`，host network，`jellyfin/jellyfin` image）
> 結果：**伺服器無誤**，根因在 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),**已恢復,無需處理**。