WEB-SABR 失败一次即自动换到能播的路线;并补齐了「把 WEB-SABR 做通」所需的取证工具 —— 借它跑出了首个双方字节对比,定位到首要嫌疑:采集回来的材料是 MWEB 身份,而我们的会话是 WEB 身份(令牌与身份不同源)。
变更
- WEB 会话被服务端拒时,自动换到能播的路线(P11-138)。此前「WEB-SABR 优先」档下若服务端把会话判死(每个请求都回
status=3令牌无效),程序会反复重建同一种注定失败的会话,直到试满重试次数 —— 实测一次 5 个会话、0 个可用分段,表现就是「完全播不了」。现在这种「建起来了但每笔请求都被拒」的失败会被记住,下次直接跳过 WEB-SABR 走 pot-less 主路(实测可播),不必再手动去设置里切。 - 取证工具补齐三处(P11-139):①我们自己的请求体日志此前被系统单行长度上限截断(丢掉的正好是请求体最后那段身份信息),改为分段输出;②采集回来的浏览器请求体内容此前根本没进日志(只有长度),补上对称的分段输出 —— 有了这两样,"我们的请求 vs 浏览器的请求"逐字段对比才第一次成立;③那条「把浏览器材料原样重放、看服务端是否接受」的判别实验此前只在特定失败分支里跑,现在挂到了必然会经过的位置。
已知问题
- WEB-SABR 仍然播不了,但原因首次被定位到字节层:对比同一份日志里的双方请求体,我们与浏览器在客户端身份上不一致 —— 浏览器(采集来源)是 MWEB(
clientName=2、带deviceMake/deviceModel、URL 里c=MWEB),我们的会话是 WEB(clientName=1、4 字段 clientInfo、URL 里c=WEB)。也就是说,浏览器那枚令牌是在 MWEB 身份下铸的,我们却以 WEB 身份使用它,服务端判为无效。这正是文档里早先记下的残留(当时那轮还能通过,所以被判为「不是判据」);现在有字节证据,它升为首要嫌疑。对齐方案已定,但按既有警告必须连同请求体形状一起改(身份与形状是耦合的),单开一轮验证。 - 升档预取本身仍未生效(历史遗留):它要回来的数据仍会被丢弃,「切档命中缓存」未达成;alpha.9 起已止住它抢占响应的副作用。
- 移动端播放器不读「默认播放倍速」:
MobilePlayerScreen把起播倍速写死 1.0x,单独跟进修复。