昵称仅供查找；修订权限按机器人收到的官方用户身份校验。
使用SMB播放高码率视频出现卡顿
使用SMB播放高码率视频出现卡顿，且实际网速和软件内显示网速差异较大 最新版相比上个版本，已经实现了以较高的网速读取SMB内容。我自测能达到100 MB每秒，接近我内网SMB的上限。但是软件内有时候会显示200 KB/s左右
我觉得这一块可以参考一下两个开源软件 mpvex 和 nextplayer，它们的做法都是使用原生的 SMB 库，然后直接把 URI 直接传给 MPV 去播放 不过显然的，因为库比较简单，所以无法实现一些高级操作🤔
本软件的实现我看得不太懂 让AI稍微分析了一下 SMB 是纯 Java 的 SMBJ 实现（com.hierynomus），所有 .so 里都没有 libsmbclient/cifs。播放链路是：
mpv loadfile http://127.0.0.1:PORT/file/ → we3 回环 HTTP 代理（支持 Range，16 KiB 分块写出） → s98 InputStream → wp8 readAt() ← 问题在这一层 → ok7 块缓存 → fb3.l() SMB2 READ（被 maxReadSize 截断）
问题在 App 自己写的块缓存层，参数和 mpv 完全割裂：
┌───────────────────────┬────────────────┐ │ │ 值 │ ├───────────────────────┼────────────────┤ │ SMB 块大小 ok7.t │ 1 MiB │ ├───────────────────────┼────────────────┤ │ 顺序读预取 ok7.u │ 8 块 = 8 MiB │ ├───────────────────────┼────────────────┤ │ 块缓存容量 ok7.v │ 12 块 = 12 MiB │ ├───────────────────────┼────────────────┤ │ mpv demuxer-max-bytes │ 32 MiB │ └───────────────────────┴────────────────┘
三个直接对症状的点
顺带两个隐患：wp8 没有 override cancelPendingReads()（seek/close 时最多 8 个 1 MiB 下载还在飞），以及任何读异常都会拆掉整个 SMB session 重连重试。
（附件或待补充反馈）
本软件的实现我看得不太懂 让AI稍微分析了一下 SMB 是纯 Java 的 SMBJ 实现（com.hierynomus），所有 .so 里都没有 libsmbclient/cifs。播放链路是： mpv loadfile http://127.0.0.1:PORT/file/ → we3 回环 HTTP 代理（支持 Range，16 KiB 分块写出） → s98 InputStream → wp8 readAt() ← 问题在这一层 → ok7 块缓存 → fb3.l() SMB2 READ（被 maxReadSize 截断） 问题在 App 自己写的块缓存层，参数和 mpv 完全割裂： ┌───────────────────────┬────────────────┐ │ │ 值 │ ├───────────────────────┼────────────────┤ │ SMB 块大小 ok7.t │ 1 MiB │ ├───────────────────────┼────────────────┤ │ 顺序读预取 ok7.u │ 8 块 = 8 MiB │ ├───────────────────────┼────────────────┤ │ 块缓存容量 ok7.v │ 12 块 = 12 MiB │ ├───────────────────────┼────────────────┤ │ mpv demuxer-max-bytes │ 32 MiB │ └───────────────────────┴────────────────┘ 三个直接对症状的点 readAt 阻塞在整块填满上——回环代理每次只问 16 KiB，但 f.a().get() 要等 1 MiB 全部下载完才返回。高码率视频的吞吐上限就被「1 MiB 块填充时间」锁死 → 卡。而系统网速监控看到的是 8 MiB 预取突发，瞬时速率很高。 预取窗口 9 MiB vs 缓存 12 MiB，历史只剩 3 MiB。mpv 的 demuxer 一旦向后 seek（读索引/续播定位）超过 3 MiB，目标块已被驱逐 → 重新冷拉 1 MiB 并再次武装 8 MiB 预取。而且顺序检测标志 ok7.c() 是 sticky 的，只置 true 从不置 false，锁上就关不掉。 SMB 层一个字节计数器都没有（wp8/ok7/fb3 全无累加）。所以 App 里显示的网速不可能是 SMB 实际吞吐，只能是从 demuxer 消费速率推出来的——和系统监控天然差一个量级，这就是你看到的「网速很高但只显示几百 KB」。 顺带两个隐患：wp8 没有 override cancelPendingReads()（seek/close 时最多 8 个 1 MiB 下载还在飞），以及任何读异常都会拆掉整个 SMB session 重连重试。
来源：Entryway QQ 用户反馈。截图、日志和文件通过本仓库附件保存，并保留 NAS 本地副本。
状态：待确认（已推送到 Phone-dev，尚未发版）
修复已推送到 Phone-dev（提交 562af78b），尚未发版，现有版本不包含本修复；请等待后续测试包复测。 注意：目前只做过编译和单元测试（手机、TV 编译通过，app/core/data/danmaku 单元测试全部通过），尚未在真机上测试。
Phone-dev
562af78b
验证：:data 文件源相关 126 项测试通过（含新增计量与重试用例），手机、TV 均编译通过；SMB 方言与加密策略未改动。本机无 NAS 环境，实际吞吐需在用户网络复测：播放高码率片源时对比系统监控与软件内显示。
:data
根因：缓存块要等整块 1MiB 下载完才可读，播放器 16KiB 的小读被单块填充时间卡住；而界面网速取自 mpv 的消费速率，和 SMB 实际收包不是同一个量。现改为：缓存块先发布被请求的前段、再按 256KiB 步进继续（4 个工作线程、按需优先排队，远距离跳转丢弃排队中的预读）；真实收包字节（含预读、不含缓存命中）单独计数，作为手机与 TV 的本地文件播放网速显示，非 SMB 来源仍回退到 mpv 数值。仅恢复真正的传输类失败一次，取消不会被误当成断线重连。 补充（评审修正）：NAS 休眠后返回的「会话过期」「文件句柄已关闭」也会自动重连一次，不再直接报错。
该工单已标记「待确认」且提交超过一周，相关改动已随新版本发布。为保持工单列表整洁，现统一关闭。
如在最新版本中仍存在该问题，欢迎在本单下回复，或新开工单并附上：版本号、设备机型与系统、具体操作步骤，必要时附日志或截图，我们会继续跟进。感谢反馈！
No dependencies set.
The note is not visible to the blocked user.
提交信息
昵称仅供查找；修订权限按机器人收到的官方用户身份校验。
当前反馈
使用SMB播放高码率视频出现卡顿
使用SMB播放高码率视频出现卡顿，且实际网速和软件内显示网速差异较大
最新版相比上个版本，已经实现了以较高的网速读取SMB内容。我自测能达到100 MB每秒，接近我内网SMB的上限。但是软件内有时候会显示200 KB/s左右
我觉得这一块可以参考一下两个开源软件 mpvex 和 nextplayer，它们的做法都是使用原生的 SMB 库，然后直接把 URI 直接传给 MPV 去播放
不过显然的，因为库比较简单，所以无法实现一些高级操作🤔
本软件的实现我看得不太懂 让AI稍微分析了一下
SMB 是纯 Java 的 SMBJ 实现（com.hierynomus），所有 .so 里都没有 libsmbclient/cifs。播放链路是：
mpv loadfile http://127.0.0.1:PORT/file/
→ we3 回环 HTTP 代理（支持 Range，16 KiB 分块写出）
→ s98 InputStream
→ wp8 readAt() ← 问题在这一层
→ ok7 块缓存
→ fb3.l() SMB2 READ（被 maxReadSize 截断）
问题在 App 自己写的块缓存层，参数和 mpv 完全割裂：
┌───────────────────────┬────────────────┐
│ │ 值 │
├───────────────────────┼────────────────┤
│ SMB 块大小 ok7.t │ 1 MiB │
├───────────────────────┼────────────────┤
│ 顺序读预取 ok7.u │ 8 块 = 8 MiB │
├───────────────────────┼────────────────┤
│ 块缓存容量 ok7.v │ 12 块 = 12 MiB │
├───────────────────────┼────────────────┤
│ mpv demuxer-max-bytes │ 32 MiB │
└───────────────────────┴────────────────┘
三个直接对症状的点
顺带两个隐患：wp8 没有 override cancelPendingReads()（seek/close 时最多 8 个 1 MiB 下载还在飞），以及任何读异常都会拆掉整个 SMB session 重连重试。
原始反馈记录
第 1 条 · 2026/10/22 17:38:05
第 2 条 · 2026/10/22 17:39:31
第 3 条 · 2026/10/22 17:39:39
第 4 条 · 2026/10/22 17:39:41
第 5 条 · 2026/10/22 17:41:03
第 6 条 · 2026/10/22 17:41:45
来源：Entryway QQ 用户反馈。截图、日志和文件通过本仓库附件保存，并保留 NAS 本地副本。
第 2 条 · 2026/10/22 17:39:31
第 3 条 · 2026/10/22 17:39:39
第 4 条 · 2026/10/22 17:39:41
第 5 条 · 2026/10/22 17:41:03
第 6 条 · 2026/10/22 17:41:45
状态：待确认（已推送到 Phone-dev，尚未发版）
修复已推送到
Phone-dev（提交562af78b），尚未发版，现有版本不包含本修复；请等待后续测试包复测。注意：目前只做过编译和单元测试（手机、TV 编译通过，app/core/data/danmaku 单元测试全部通过），尚未在真机上测试。
验证：
:data文件源相关 126 项测试通过（含新增计量与重试用例），手机、TV 均编译通过；SMB 方言与加密策略未改动。本机无 NAS 环境，实际吞吐需在用户网络复测：播放高码率片源时对比系统监控与软件内显示。根因：缓存块要等整块 1MiB 下载完才可读，播放器 16KiB 的小读被单块填充时间卡住；而界面网速取自 mpv 的消费速率，和 SMB 实际收包不是同一个量。现改为：缓存块先发布被请求的前段、再按 256KiB 步进继续（4 个工作线程、按需优先排队，远距离跳转丢弃排队中的预读）；真实收包字节（含预读、不含缓存命中）单独计数，作为手机与 TV 的本地文件播放网速显示，非 SMB 来源仍回退到 mpv 数值。仅恢复真正的传输类失败一次，取消不会被误当成断线重连。
补充（评审修正）：NAS 休眠后返回的「会话过期」「文件句柄已关闭」也会自动重连一次，不再直接报错。
该工单已标记「待确认」且提交超过一周，相关改动已随新版本发布。为保持工单列表整洁，现统一关闭。
如在最新版本中仍存在该问题，欢迎在本单下回复，或新开工单并附上：版本号、设备机型与系统、具体操作步骤，必要时附日志或截图，我们会继续跟进。感谢反馈！