上一版(alpha.9)的预取撤销没生效 —— 真机复测发现它挂在了故障时根本不会被走到的那条路上。本版把它搬到真正会走到的地方,并补上丢弃流量的取证。
变更
- 预取改为「一发现没拿到数据就撤销」(P11-137)。alpha.9 的撤销挂在"取下一块数据"的入口上,但故障发生时加载器正卡在重试同一个分段的循环里,那个入口一次都不会被调用(实测 32 秒里只有 1 次),于是整场没打出一条撤销日志、暴风照旧:一次 12 次重试、每次白下约 7.6MB(合计 ≈91MB),缓冲从 29.5 秒被吃空到 5.8 秒,卡顿 2.6 秒。现在撤销挂在每一笔重试都会经过的位置:只要本次响应里没有我们要的分段,立刻撤销预取 —— 下一笔重试就能把分段拿回来,不必干等 30 秒窗口自然过期(那之前每笔都在白下 8MB)。
- 新增诊断:被丢弃的流量取证。日志会打出
discarded media: XB of YB (itags=[…])—— 量化每笔响应里"下载完又整段丢掉"的字节量,用来决定带宽统计口径要不要跟着改。本版只观测,不改口径。 - 诊断可读性三项:播放状态日志补上状态名(
playerState=3(READY)而不是只打数字 —— 这正是之前复盘读反、把正常播放当成卡死窗口的原因);两个重试预算的日志分开喊名并带上限(此前都写 "counter reset",分不清清的是哪一个)。
已知问题
- 升档预取本身仍未生效:它要回来的数据依然会被整段丢弃(格式不在"当前播放的格式"里),「切档命中缓存、不必现拉」这个目标仍未达成。本版依旧只是止住它抢占响应的副作用。若这次真机复测仍不能止住,按既定决策直接删掉预取(把带宽还给正在播放的清晰度),升档维持现拉(720→1080 约 2.9s、1080→1440 约 6.6s、1440→2160 约 14.3s)。
- 移动端播放器不读「默认播放倍速」:
MobilePlayerScreen把起播倍速写死 1.0x,该设置在移动端一直失效,单独跟进修复。 - 服务端偶发改推其它清晰度 / 跳过所请求的分段:这条仍未处理,与预取是两回事(见 docs §34.3 / §34.4)。