昵称仅供查找；修订权限按机器人收到的官方用户身份校验。
[Bug] 4K HEVC 103Mbps DirectPlay 只有 0.66× 实时：单连接取流上限约 78Mbps，同机 Kodi 同片可到 149Mbps
环境
项 值 设备 Xiaomi TV S Pro Mini LED（MiTV-MFTR0） SoC MediaTek MT9653（ro.board.platform=mt5879），4×Cortex-A73 内存 3.86 GB（totalMem 3860 MiB） 系统 Android 14（SDK 34），HyperOS 3.0.101.0.UFTMATV ABI armeabi-v7a,armeabi（纯 32 位，无 arm64） 客户端 com.entryway.tv v1.0.13（versionCode 57，targetSdk 36） 服务端 Emby 4.10.0.40，局域网，DirectPlay 网络 Wi-Fi 6 5GHz，RSSI -19dBm，协商 1201Mbps（5320MHz） 性能模式 手动设为「高端（满血）」
现象
播放 4K HEVC 10bit HDR10 原盘（平均码率 103.2Mbps，76.3GB / 99min）：
服务端 PlayMethod=DirectPlay，无 TranscodingInfo
播放位置推进 43.9 秒 / 墙钟 67.0 秒 = 0.66×，周期性停顿转圈
电视侧 wlan0 实际接收：61–91Mbps，均值 78Mbps（3 秒粒度采样）
到 CDN 只有一条长连接（单流累计 1.45GB），不是多分片并行
关键：性能模式「高端」确已生效，但依然饿死
EntrywayTier 日志（播放器创建时打印）：
I EntrywayTier: Exo tier=HIGH targetBytes=178956970 durations=45000/120000/3000/5000 back=12000
targetBytes = 178,956,970 字节 = 170.7 MiB，按 103.2Mbps 折算 = 13.9 秒缓冲
对比默认 MID 档的 80MiB（6.2 秒），档位参数（minBufferMs 45s / maxBufferMs 120s）整套都换过来了
即便如此，播放中仍在刷：
W DefaultLoadControl: Target buffer size reached with less than 500ms of buffered media data.
170MiB 的字节预算被打到 500ms 以下，说明瓶颈不是缓冲预算，而是供给速度本身。
同机对照：Kodi 能跑到 149Mbps
同一台电视、同一部片、同一条 302 直链、同一时间（Kodi 走 Emby 插件模式，最终仍直连移动 CDN，111.13.x / 111.62.x，不是 NAS 中转）：
播放器 wlan0 均值 峰值 播放推进 Entryway（HIGH 档） 78 Mbps 91 0.66× Kodi 21.3 149 Mbps 199 1.0×（8 分 05 秒 / 8.2%）
同一条 Wi-Fi 链路（-19dBm、1201Mbps）能稳定送来 149Mbps，所以链路、CDN 总量、片源都没有问题。
另一个差异：连接数
Entryway：只有一条 TCP 长连接承担全部取流（1.45GB 全在一条流上）
Kodi：同时有多条连接打到不同 CDN 节点并行取
这与本机在服务端侧测到的规律一致：单连接 ~100Mbps，6 并发 ~400–700Mbps。
已排除
环节 实测 服务端转码 无 TranscodingInfo；日志无 StreamTranscode CDN 节点 / UA 差异化 同一 URL 用 Entryway-TV/1.0.13 (android; 34) 与 Kodi UA 取 302，Location 的 host 与对象 key 完全相同 HTTP/2 强制 --http2 仍协商回 HTTP/1.1 CDN 取流上限 局域网 5 种 UA 12 秒连续拉流 52–93MB/s（420–745Mbps）；钉到电视解析出的 CDN IP 仍 92.1MB/s 设备闪存 dd 写 400MB：178MB/s（磁盘缓存不是瓶颈） 设备 Wi-Fi RSSI -19dBm，协商 1201Mbps，未降速 缓冲预算 HIGH 档 170.7MiB 仍被打空（见上）
推断
不是网络、不是 CDN、不是 Wi-Fi、不是服务端转码。
不是 targetBytes 太小：把它从 80MiB 提到 170.7MiB 后，吞吐确实从 ~55Mbps 升到 ~78Mbps，但没有质变，仍然低于片源码率。
是单连接取流的吞吐上限：同机 Kodi 多连接可以到 149Mbps，Entryway 单连接停在 78Mbps 左右（约 9.75MB/s）。
缓冲放大带来的一点提升也符合这个判断——加大预算等于加大单连接的在途窗口（BDP），但单连接本身的上限没变。
建议排查点（供参考，不强制）
多连接分段 Range：按 8–16MB 分段、2–4 路并行取流（播放器侧合成一个连续流），这是 Kodi 与多数高码率播放器的做法。
单连接效率：检查 OkHttp 的 socket buffer / 读缓冲大小、是否启用 TLS 零拷贝、32 位进程里是否有额外的内存拷贝；同样链路下 Kodi 能到 149Mbps 说明还有很大空间。
按码率自适应：bitrate > 60Mbps 时自动切多连接模式，低码率仍用单连接省开销。
目前 EntrywayTier 这行日志非常好用（档位 + targetBytes + 四段时长一次给全），建议保留。
备注
本机为纯 32 位系统（abilist=armeabi-v7a），无法安装 64 位构建；按 DeviceTierPolicy 规则 HIGH 需要 is64BitProcess，这台机器是手动强制到 HIGH 的。
复现素材不需要我的私有链接：用本地 HTTP 服务挂一个 ≥100Mbps 的 4K HEVC 文件即可复现，关键是平均码率高于单连接取流上限。
另一个独立问题（杜比视界 P7 切换/跳转瞬间 dequeueInputBuffer failed 刷屏）不属本 issue，另行反馈。
关于原盘高码率会卡的排查，主要排查原因应该是性能模式被强制分配为MID导致缓存不够所以播放不流畅
（附件或待补充反馈）
下载附件：entryway-issue-v5.md（8245 字节）
合并104,152的反馈
来源：Entryway QQ 用户反馈。截图、日志和文件通过本仓库附件保存，并保留 NAS 本地副本。
提出者：甜岑啵啵🍊
关于原盘高码率会卡的排查，主要排查原因应该是性能模式被强制分配为MID导致缓存不够所以播放不流畅 合并104,152的反馈
新测试数据，开了high还是会卡，问题还是出在单线程取流上
[Bug] 4K HEVC 103Mbps DirectPlay 只有 0.66× 实时：单连接取流上限约 78Mbps，同机 Kodi 同片可到 149Mbps 环境 项 值 设备 Xiaomi TV S Pro Mini LED（MiTV-MFTR0） SoC MediaTek MT9653（ro.board.platform=mt5879），4×Cortex-A73 内存 3.86 GB（totalMem 3860 MiB） 系统 Android 14（SDK 34），HyperOS 3.0.101.0.UFTMATV ABI armeabi-v7a,armeabi（纯 32 位，无 arm64） 客户端 com.entryway.tv v1.0.13（versionCode 57，targetSdk 36） 服务端 Emby 4.10.0.40，局域网，DirectPlay 网络 Wi-Fi 6 5GHz，RSSI -19dBm，协商 1201Mbps（5320MHz） 性能模式 手动设为「高端（满血）」 现象 播放 4K HEVC 10bit HDR10 原盘（平均码率 103.2Mbps，76.3GB / 99min）： 服务端 PlayMethod=DirectPlay，无 TranscodingInfo 播放位置推进 43.9 秒 / 墙钟 67.0 秒 = 0.66×，周期性停顿转圈 电视侧 wlan0 实际接收：61–91Mbps，均值 78Mbps（3 秒粒度采样） 到 CDN 只有一条长连接（单流累计 1.45GB），不是多分片并行 关键：性能模式「高端」确已生效，但依然饿死 EntrywayTier 日志（播放器创建时打印）： I EntrywayTier: Exo tier=HIGH targetBytes=178956970 durations=45000/120000/3000/5000 back=12000 targetBytes = 178,956,970 字节 = 170.7 MiB，按 103.2Mbps 折算 = 13.9 秒缓冲 对比默认 MID 档的 80MiB（6.2 秒），档位参数（minBufferMs 45s / maxBufferMs 120s）整套都换过来了 即便如此，播放中仍在刷： W DefaultLoadControl: Target buffer size reached with less than 500ms of buffered media data. 170MiB 的字节预算被打到 500ms 以下，说明瓶颈不是缓冲预算，而是供给速度本身。 同机对照：Kodi 能跑到 149Mbps 同一台电视、同一部片、同一条 302 直链、同一时间（Kodi 走 Emby 插件模式，最终仍直连移动 CDN，111.13.x / 111.62.x，不是 NAS 中转）： 播放器 wlan0 均值 峰值 播放推进 Entryway（HIGH 档） 78 Mbps 91 0.66× Kodi 21.3 149 Mbps 199 1.0×（8 分 05 秒 / 8.2%） 同一条 Wi-Fi 链路（-19dBm、1201Mbps）能稳定送来 149Mbps，所以链路、CDN 总量、片源都没有问题。 另一个差异：连接数 Entryway：只有一条 TCP 长连接承担全部取流（1.45GB 全在一条流上） Kodi：同时有多条连接打到不同 CDN 节点并行取 这与本机在服务端侧测到的规律一致：单连接 ~100Mbps，6 并发 ~400–700Mbps。 已排除 环节 实测 服务端转码 无 TranscodingInfo；日志无 StreamTranscode CDN 节点 / UA 差异化 同一 URL 用 Entryway-TV/1.0.13 (android; 34) 与 Kodi UA 取 302，Location 的 host 与对象 key 完全相同 HTTP/2 强制 --http2 仍协商回 HTTP/1.1 CDN 取流上限 局域网 5 种 UA 12 秒连续拉流 52–93MB/s（420–745Mbps）；钉到电视解析出的 CDN IP 仍 92.1MB/s 设备闪存 dd 写 400MB：178MB/s（磁盘缓存不是瓶颈） 设备 Wi-Fi RSSI -19dBm，协商 1201Mbps，未降速 缓冲预算 HIGH 档 170.7MiB 仍被打空（见上） 推断 不是网络、不是 CDN、不是 Wi-Fi、不是服务端转码。 不是 targetBytes 太小：把它从 80MiB 提到 170.7MiB 后，吞吐确实从 ~55Mbps 升到 ~78Mbps，但没有质变，仍然低于片源码率。 是单连接取流的吞吐上限：同机 Kodi 多连接可以到 149Mbps，Entryway 单连接停在 78Mbps 左右（约 9.75MB/s）。 缓冲放大带来的一点提升也符合这个判断——加大预算等于加大单连接的在途窗口（BDP），但单连接本身的上限没变。 建议排查点（供参考，不强制） 多连接分段 Range：按 8–16MB 分段、2–4 路并行取流（播放器侧合成一个连续流），这是 Kodi 与多数高码率播放器的做法。 单连接效率：检查 OkHttp 的 socket buffer / 读缓冲大小、是否启用 TLS 零拷贝、32 位进程里是否有额外的内存拷贝；同样链路下 Kodi 能到 149Mbps 说明还有很大空间。 按码率自适应：bitrate > 60Mbps 时自动切多连接模式，低码率仍用单连接省开销。 目前 EntrywayTier 这行日志非常好用（档位 + targetBytes + 四段时长一次给全），建议保留。 备注 本机为纯 32 位系统（abilist=armeabi-v7a），无法安装 64 位构建；按 DeviceTierPolicy 规则 HIGH 需要 is64BitProcess，这台机器是手动强制到 HIGH 的。 复现素材不需要我的私有链接：用本地 HTTP 服务挂一个 ≥100Mbps 的 4K HEVC 文件即可复现，关键是平均码率高于单连接取流上限。 另一个独立问题（杜比视界 P7 切换/跳转瞬间 dequeueInputBuffer failed 刷屏）不属本 issue，另行反馈。
No dependencies set.
The note is not visible to the blocked user.
修订历史
提交信息
昵称仅供查找；修订权限按机器人收到的官方用户身份校验。
当前反馈
[Bug] 4K HEVC 103Mbps DirectPlay 只有 0.66× 实时：单连接取流上限约 78Mbps，同机 Kodi 同片可到 149Mbps
环境
项 值
设备 Xiaomi TV S Pro Mini LED（MiTV-MFTR0）
SoC MediaTek MT9653（ro.board.platform=mt5879），4×Cortex-A73
内存 3.86 GB（totalMem 3860 MiB）
系统 Android 14（SDK 34），HyperOS 3.0.101.0.UFTMATV
ABI armeabi-v7a,armeabi（纯 32 位，无 arm64）
客户端 com.entryway.tv v1.0.13（versionCode 57，targetSdk 36）
服务端 Emby 4.10.0.40，局域网，DirectPlay
网络 Wi-Fi 6 5GHz，RSSI -19dBm，协商 1201Mbps（5320MHz）
性能模式 手动设为「高端（满血）」
现象
播放 4K HEVC 10bit HDR10 原盘（平均码率 103.2Mbps，76.3GB / 99min）：
服务端 PlayMethod=DirectPlay，无 TranscodingInfo
播放位置推进 43.9 秒 / 墙钟 67.0 秒 = 0.66×，周期性停顿转圈
电视侧 wlan0 实际接收：61–91Mbps，均值 78Mbps（3 秒粒度采样）
到 CDN 只有一条长连接（单流累计 1.45GB），不是多分片并行
关键：性能模式「高端」确已生效，但依然饿死
EntrywayTier 日志（播放器创建时打印）：
I EntrywayTier: Exo tier=HIGH targetBytes=178956970 durations=45000/120000/3000/5000 back=12000
targetBytes = 178,956,970 字节 = 170.7 MiB，按 103.2Mbps 折算 = 13.9 秒缓冲
对比默认 MID 档的 80MiB（6.2 秒），档位参数（minBufferMs 45s / maxBufferMs 120s）整套都换过来了
即便如此，播放中仍在刷：
W DefaultLoadControl: Target buffer size reached with less than 500ms of buffered media data.
170MiB 的字节预算被打到 500ms 以下，说明瓶颈不是缓冲预算，而是供给速度本身。
同机对照：Kodi 能跑到 149Mbps
同一台电视、同一部片、同一条 302 直链、同一时间（Kodi 走 Emby 插件模式，最终仍直连移动 CDN，111.13.x / 111.62.x，不是 NAS 中转）：
播放器 wlan0 均值 峰值 播放推进
Entryway（HIGH 档） 78 Mbps 91 0.66×
Kodi 21.3 149 Mbps 199 1.0×（8 分 05 秒 / 8.2%）
同一条 Wi-Fi 链路（-19dBm、1201Mbps）能稳定送来 149Mbps，所以链路、CDN 总量、片源都没有问题。
另一个差异：连接数
Entryway：只有一条 TCP 长连接承担全部取流（1.45GB 全在一条流上）
Kodi：同时有多条连接打到不同 CDN 节点并行取
这与本机在服务端侧测到的规律一致：单连接 ~100Mbps，6 并发 ~400–700Mbps。
已排除
环节 实测
服务端转码 无 TranscodingInfo；日志无 StreamTranscode
CDN 节点 / UA 差异化 同一 URL 用 Entryway-TV/1.0.13 (android; 34) 与 Kodi UA 取 302，Location 的 host 与对象 key 完全相同
HTTP/2 强制 --http2 仍协商回 HTTP/1.1
CDN 取流上限 局域网 5 种 UA 12 秒连续拉流 52–93MB/s（420–745Mbps）；钉到电视解析出的 CDN IP 仍 92.1MB/s
设备闪存 dd 写 400MB：178MB/s（磁盘缓存不是瓶颈）
设备 Wi-Fi RSSI -19dBm，协商 1201Mbps，未降速
缓冲预算 HIGH 档 170.7MiB 仍被打空（见上）
推断
不是网络、不是 CDN、不是 Wi-Fi、不是服务端转码。
不是 targetBytes 太小：把它从 80MiB 提到 170.7MiB 后，吞吐确实从 ~55Mbps 升到 ~78Mbps，但没有质变，仍然低于片源码率。
是单连接取流的吞吐上限：同机 Kodi 多连接可以到 149Mbps，Entryway 单连接停在 78Mbps 左右（约 9.75MB/s）。
缓冲放大带来的一点提升也符合这个判断——加大预算等于加大单连接的在途窗口（BDP），但单连接本身的上限没变。
建议排查点（供参考，不强制）
多连接分段 Range：按 8–16MB 分段、2–4 路并行取流（播放器侧合成一个连续流），这是 Kodi 与多数高码率播放器的做法。
单连接效率：检查 OkHttp 的 socket buffer / 读缓冲大小、是否启用 TLS 零拷贝、32 位进程里是否有额外的内存拷贝；同样链路下 Kodi 能到 149Mbps 说明还有很大空间。
按码率自适应：bitrate > 60Mbps 时自动切多连接模式，低码率仍用单连接省开销。
目前 EntrywayTier 这行日志非常好用（档位 + targetBytes + 四段时长一次给全），建议保留。
备注
本机为纯 32 位系统（abilist=armeabi-v7a），无法安装 64 位构建；按 DeviceTierPolicy 规则 HIGH 需要 is64BitProcess，这台机器是手动强制到 HIGH 的。
复现素材不需要我的私有链接：用本地 HTTP 服务挂一个 ≥100Mbps 的 4K HEVC 文件即可复现，关键是平均码率高于单连接取流上限。
另一个独立问题（杜比视界 P7 切换/跳转瞬间 dequeueInputBuffer failed 刷屏）不属本 issue，另行反馈。
原始反馈记录
第 1 条 · 2026/10/29 13:47:26
第 2 条 · 2026/10/29 13:47:33
下载附件：entryway-issue-v5.md（8245 字节）
第 3 条 · 2026/10/29 13:48:20
来源：Entryway QQ 用户反馈。截图、日志和文件通过本仓库附件保存，并保留 NAS 本地副本。
第 2 条 · 2026/10/29 13:47:33
下载附件：entryway-issue-v5.md（8245 字节）
第 3 条 · 2026/10/29 13:48:20
原提出者修订记录
提出者：甜岑啵啵🍊
修订前
修订后
[Bug] 关于原盘高码率会卡的排查，主要排查原因应该是性能模式被强制分配为MID导致缓存不…to [Bug] 新测试数据，开了high还是会卡，问题还是出在单线程取流上原提出者修订记录
提出者：甜岑啵啵🍊
修订前
修订后
[Bug] 新测试数据，开了high还是会卡，问题还是出在单线程取流上to [Bug] [Bug] 4K HEVC 103Mbps DirectPlay 只有 0.66…