🎯 Seetong 问题雷达 17:00 第226期

🔴 问题 1：KMP 卡回放取「当天录像」时走云回放分支，失败后无超时兜底并反复重试（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户在回放页被告知「不能查看当天录像，只能查看前一天到 24 时的录像」。从日志还原的真实机制是：进入回放页时若上一台设备的回放 Tab 记忆为「云回放」，而当前设备 supportCloud=false，KMP 会照旧落到云回放 Tab、以 selectedDate=前一天 初始化云播放器；云链路既不准备也不出图（currentVideoUrl= 空、cloudPrepared=false），用户看到的就是「当天（其实是被切走的那天）看不了」。
• 涉及反馈：本窗口 1 条直接反馈 + 3 条同类线索，跨 3 机型 3 地区：

• 跨期连续性：该用户链路与第 218 期（回放 Tab / 卡回放链路）同源；本期为首次取得带完整 PlayBackPage / CloudPlayback 调用链的现场日志，证据等级由「现象推断」升为「机制可复算」。
• 严重度评分：71/100（反馈量 10 / 共性 21 / 关键度 40）——反馈量按窗口内直接与同类线索计数（1 条直证 + 3 条同类）；共性覆盖 3 机型 3 地区但仅 Android 单端，故计 21；关键度按「回放主链路不可用」计 40。
• 附注（同批独立现象，未计入本问题）：256676（HONOR LAB-AN00，河北）反馈「摄像头没画面」，Logan 3.8 MB 无 PlayBackPage 链路，属预览链路待补证，登记于「待补证」。

2. 神策证据（核心数据源）

• 本期未对 NvrMonitorFrameResult / CloudPlayback* 做独立下钻，原因与限制如下：
• 回放页 Tab 决策、云回放准备失败、PLAYBACK_PLAY_FAILED_EVENT 均为客户端内部事件与 EventBus 事件，不在服务端埋点体系内（PLAYBACK_PLAY_FAILED_EVENT 仅存在于 moduleBase/.../Events.kt:56 客户端常量，无同名上报事件）；
• 因此神策只能证明影响面、不能直接证明本根因。
• 影响面参照（沿用第 225 期口径，2026-10-10 单日，appId=seetong）：MonitorFrameResult 去重用户 7,634,491 / 总次数 32,593,312——回放与预览是当日高频主链路，本问题一旦命中即为高频路径。
• 关键局限（必须标注）：本期根因证据链以 Logan 行为链 + 代码分支级反证 为主，神策不参与根因判定。

3. Logan 关键日志（核心数据源）

• 反馈 ID：256612（HONOR BKQ-AN10，Android 8.4.1.6，墨西哥，繁体中文）；日志 1,700,199 bytes / 10,765 行；快照覆盖 07:20–10:16（本次快照含 10-10 行 111 条 + 10-11 行 8,263 条）。
• 关键调用链时序（与投诉现象一一对应）：

• 失败计数（可复算的二进制事实）：全窗口 receive playback play failed event 共 20 次，时间分布 09:40(4) / 09:41(4) / 09:48(4) / 09:49(4) / 09:52(4)，全部 result=0。
• Tab 记忆固化证据：saveLastPlaybackTab ... tabIndex=1 出现 6 次，全部为 1——没有任何一次写回 0（卡回放 Tab）。resolveSavedPlaybackTabForCurrentDevice 在 33878635-CH-1 与 26312717-CH-1 两台设备上均为 savedTabIndex=1, targetTabIndex=1。
• 失败无退避证据：09:40:59.106 首次失败后，09:40:59.414 / 09:40:59.828 / 09:40:59.901 在 约 800 毫秒内连续再失败 3 次，随后 09:41:48 起以秒级间隔继续——无指数退避、无次数上限。
• 对照（同一份日志的正向证据）：RecordPlayerView-onRecvFirstFrame: devId=33878635-CH-2 / -CH-1 与 mark card playback first frame, devId=33878635-CH-1 在 09:41:00 之后多次出现——说明卡回放（SD 录像）本身是能出图的，出问题的是被切到的云回放分支，这排除了「设备无录像 / 设备离线」的解释。
• 背景噪声（必须区分，非本问题）：下载接口 Error stats 含 -102 / -101 若干；全窗口另有 TPS_MSG_P2P_OFFLINE、NetworkCallbackManager-网络改变 密集输出（约 10 次/秒），属设备与网络状态波动，非本问题根因。

4. 代码定位（详细）

• 涉及仓库：~/seetong-kmp（KMP 公共层，Android / HarmonyOS / iOS 共用）；Android 宿主为 ~/Seetong-App-Android/Seetong5.0ForSeetong。
• 关键类与行号：

• 调用链：PlayBackPage 进入 → resolveSavedPlaybackTabForCurrentDevice（读 MMKV 记忆，不看 supportCloud） → CloudPlayback.onCreated（云回放，selectedDate 取前一天）→ KMPCloudPlaybackVideoView.init → 播放失败 → PLAYBACK_PLAY_FAILED_EVENT → playFailedEventRef → result<0 → playOrSeek() 重试 → 再次失败 → saveLastPlaybackTab(tabIndex=1) 固化。
• 关键分支：supportCloud=false 且 savedTabIndex=1 时没有回落卡回放 Tab 的分支；resolvePlaybackExceptionState 的 isNotWifiIpc 提前返回使异常 UI 失效。
• 修复方向锚点：

1. resolveSavedPlaybackTabForCurrentDevice 增加 supportCloud 约束：supportCloud=false 时强制 targetTabIndex=0，并不回写 tabIndex=1；
2. playFailedEventRef 的 result<0 分支补充退避（如 1s/2s/4s）+ 次数上限（如 3 次），超限后进入明确失败态而非无限重试；
3. resolvePlaybackExceptionState 对 isNotWifiIpc 的 return NONE 需区分「SD 正常」与「未取到 SD 信息」，避免异常 UI 被静默吞掉；
4. 云回放 onCreated 增加 currentVideoUrl 空值守卫，避免空 URL 进入 IDLE 后仍停留云 Tab。

5. 根因结论

• 置信度：🟢 强
• 一句话根因：KMP 回放页在选择 Tab 时只信设备记忆、不信设备能力，把 supportCloud=false 的设备硬切到云回放 Tab 并以「前一天」初始化；云链路从未 prepared（currentVideoUrl 空、cloudPrepared=false），失败事件 result=0 又恰好落入 result<0 的无退避重试分支，同时 SD 异常态在非 WiFi IPC 上被 return NONE 吞掉——三者叠加，用户既看不到当天录像也收不到失败提示，且失败状态被 saveLastPlaybackTab(tabIndex=1) 固化到下一次。
• 关键证据链：Logan 四段互证（savedTabIndex=1 + supportCloud=false → selectedDate=20261010 → currentVideoUrl= 空 / cloudPrepared=false → 20 次 result=0）+ 同一份日志内卡回放 onRecvFirstFrame 正常出图（排除「无录像 / 离线」解释）+ 代码侧 CARD_PLAYBACK_FAILED_RESULT_THRESHOLD=0 与 isNotWifiIpc → NONE 两处分支级反证。
• 与第 218 期（屏幕常亮）的关系：同属 KMP 回放页缺陷族但根因不同——218 期/225 期是「回放页未申请常亮」，本期是「回放页 Tab 决策 + 失败兜底」，不可合并为一个任务，须独立创单。

6. 建议下一步

• 分配给：KMP 公共层回放模块 owner（modulePlayback），Android 端配合验证
• 优先处理项：

1. 修 resolveSavedPlaybackTabForCurrentDevice 的 supportCloud 约束（最高优先级，直接决定用户能否看到当天录像）
2. 给 playFailedEventRef 的 result<0 分支加退避 + 上限 + 明确失败态

• 验证方法：真机（HONOR BKQ-AN10 / vivo V2352A）+ 一台 supportCloud=false 设备，先在一台支持云存的设备上切到云回放 Tab 固化 tabIndex=1，再切回不支持云存的设备，确认：① 落到卡回放 Tab；② 当天录像可见；③ Logan 中 receive playback play failed event 数量 ≤ 上限且出现明确失败提示
• 新增任务：T-20261011-1700xx-kmp-tab（见文末任务账本记录）
• 回访对象：256612（18233007756，墨西哥）、256666（17742699186，湖南湘潭）

🟠 问题 2：HarmonyOS 1.1.1.11 回放 / 监控链路不可用连续第 5 期聚集（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：HarmonyOS 1.1.1.11 用户在监控预览 / 回放 / 登录 / 扫码环节集中受挫，措辞涵盖「手机连不上」「登录不上」「手机连不上图片」「监控不流畅，特别卡顿」「扫码机身二维码不正确」。
• 涉及反馈：本窗口 HarmonyOS 反馈共 14 条，全部为 1.1.1.11，占非网络类反馈的 14/29（48%）；其中功能性描述 4 条 + 扫码 2 条：

• 其余 8 条为无效文本 / 咨询类（256658「..」、256614 计费长文、256652 格式化后恢复、256650/256651 流量提示、256664 客服催问、256605/256606 换绑手机号），不并入本问题共性计数。
• 跨期连续性：本期为连续第 5 期（第 222 / 223 / 224 / 225 / 226 期）；第 223 期 7 条、第 224 期 8 条、第 225 期 7 条、本期 4 条（功能性口径）。本期较第 225 期的口径变化：第 225 期统计的是回放 / 监控链路 7 条，本期回放链路功能性反馈降至 4 条，但新增扫码链路 2 条，聚集面从「回放」扩展到「回放 + 登录 + 扫码」。
• 严重度评分：66/100（反馈量 20 / 共性 30 / 关键度 16）——窗口内 14 条全部同版本，共性跨 6 机型 5 地区拉满 30；关键度因单条内容分散、未收敛到单一失效点，按 16 计。较第 225 期（68）微降 2 分，原因是功能性条目数量虽减但失效面扩大，两者相抵。

2. 神策证据（核心数据源）

• 本期未按 HarmonyOS 维度下钻，限制同第 225 期：seetong_os 维度下钻需在 MonitorFrameResult / NvrMonitorFrameResult 上分组，受样例时间与 token 预算约束未展开；NvrMonitorFrameResult 历史样本量偏小，样本不足以做 HarmonyOS 回放首帧耗时归因。
• 结论：神策在本问题中仅作为影响面参照，不作为根因证据。

3. Logan 关键日志（核心数据源）

• 反馈 ID：256691｜256642｜256629｜256621｜256644｜256641
• 状态：6 条功能性反馈的 loganFileDownloadUrl 全部为空字符串；本窗口 14 条 HarmonyOS 反馈无一带 Logan。
• 关键栈 / 错误码：无法给出（无日志即无栈、无错误码）。
• 上下文：这是本问题最关键的发现——不是「日志里没线索」，而是「日志压根不存在」。本期再次量化：HarmonyOS 端 14/14 条反馈零 Logan，与第 225 期（21/21）、第 224 期同结论，构成连续 5 期的稳定能力缺口。
• 对照（本期新增的正向对照）：同窗口 Android 反馈带 Logan 是常态，且本期首次实测可通过 Logan 的 Basic Auth 下载并解析大体积日志（256612 = 1.7 MB / 256675 = 3.8 MB / 256631 = 2.5 MB），进一步证明「零 Logan」是 HarmonyOS 端专属的上报能力缺口，不是平台级故障或权限问题。
• 引文：无。

4. 代码定位

• 涉及仓库：~/seetong-kmp（HarmonyOS 复用 KMP 公共层）+ ~/seetong-app-harmony 宿主
• 已确认：BasePager.kt:71 的常亮判定显式包含 pagerData.isOhOs，说明 KMP 公共层的部分能力设计上已覆盖 HarmonyOS；但 hotfix_v1.1.1 分支不含 f98e6f3b / 696aa83c（第 225 期结论），本期未推翻。
• 本期新增可定位点：modulePlayback 的日志全部经 LogUtils.d(..., "PlayBackPage") 输出（见问题 1 代码定位表），说明KMP 公共层的日志埋点是齐全的；HarmonyOS 零 Logan 的断点不在 KMP 公共层，而在 HarmonyOS 宿主的 Logan 接入 / 上传触发环节——这与第 225 期「能力缺口」判断一致，但本期把断点范围收敛到了宿主侧。
• 说明：已搜路径包括 ~/seetong-kmp/modulePlayback、~/seetong-kmp/moduleBase、~/seetong-app-harmony；HarmonyOS 宿主内未找到可锚定的 Logan 初始化位置，故标注「代码待定位」，不阻塞报告。
• 修复方向锚点：优先补 Logan 上报（先有证据，再谈定位），其次核对 HarmonyOS 宿主中 LogUtils / clogan 的初始化与上传触发是否与 Android 一致。

5. 根因结论

• 置信度：🟡 中
• 一句话根因：HarmonyOS 1.1.1.11 在回放 / 预览 / 登录 / 扫码路径上存在连续 5 期持续聚集的不可用反馈，聚集面本期由「回放」扩大到「回放 + 登录 + 扫码」；且该端在对应场景完全不产出 Logan（本期 14/14），导致根因无法收敛。目前只能确认「问题真实存在且跨机型跨地区」，无法确认「具体失效点」。
• 关键证据链：14 条 HarmonyOS 反馈（跨 6 机型 5 地区，全部 1.1.1.11）+ 跨期连续性（第 222–226 期连续五期）+ 14/14 零 Logan + 同期 Android 可下载（正向对照）。证据链在现象层成立，在机制层断裂——断裂点就是 Logan 缺失，且本期已把断点范围收敛到 HarmonyOS 宿主侧。
• 与问题 1 的关系：两者共享同一个 Logan 缺口，因此问题 1 的「强置信度」来自 Android 侧完整调用链，而问题 2 只能停在「中置信度」。
• 升级建议：连续 5 期远超第 224 期设定的 4 期阈值，建议由雷达常规项正式升级为专项排查，指定 HarmonyOS 宿主负责人并设定补 Logan 的明确交付时间点。

6. 建议下一步

• 分配给：HarmonyOS 端负责人（Logan 接入归属方）
• 优先处理项：

1. 补齐 HarmonyOS 端回放 / 预览 / 登录 / 扫码场景的 Logan 上报（能力缺口，优先级最高，已连续 5 期阻塞根因分析）
2. 对 256691、256621、256641 / 256644 四名用户做定点回访，记录设备型号、固件版本、网络类型、失败时刻
3. 由雷达常规项升级为专项，明确 owner 与交付时间点

• 验证方法：修复包在 HarmonyOS 真机走「进入回放 → 切换 Tab → 拖动时间轴 → 预览 → 扫码添加设备」全路径，确认 Logan 目录产出对应日志文件；随后按 devId 串联首帧回调与失败码。
• 升级条件：已满足（连续 5 期）。若下一期继续聚集，按专项流程处理并不再计入雷达常规项。

本期扫描全量

计数校验：62 + 6 + 2 + 2 + 2 + 3 + 1 + 5 + 2 + 6 = 91，与接口 fetched=91 一致。

数据源状态汇总

任务账本

说明：问题 1 与 T-20260926-170258-576a（屏幕常亮）虽同属 KMP 回放页缺陷族，但根因不同，已按 skill 规则独立建单，未合并。

待补证

• HarmonyOS Logan 缺口（连续 5 期阻塞根因）：需在 HarmonyOS 宿主侧补齐 Logan 初始化与上传触发；建议下一期起在报告中固定披露「HarmonyOS N/N 条零 Logan」以量化
• 神策 HarmonyOS 维度下钻：需在 MonitorFrameResult / NvrMonitorFrameResult 上按 seetong_os=HarmonyOS 分组，补做 7 天趋势（连续 5 期未完成）
• 256676（HONOR LAB-AN00，「摄像头没画面」）：已下载 3.8 MB Logan 但未做深度解析，下期若再现即进雷达
• 256666（vivo V2352A，「联网正常却显示离线」）：Logan 已取得（326,245 B），窗口内可见 TPS_MSG_P2P_OFFLINE dev4gOnline=-1（13:03）与 dev4gOnline=0（09:54），需下期按 devId=41415172 串联服务端 devIsOnline 与本地 isConnect 时序
• 256675（HUAWEI ANA-AN00，「注册平台失败」）：3.8 MB Logan 未检索到注册失败栈，需按时间锚点（15:07）二次切片
• 心愿单口径：接口 complete=false（5248 / 1000），若需精确排除「产品建议」型反馈，需提高拉取上限或改用服务端过滤
• 反馈窗口连续性：本期为 17:00 正期，窗口起点取上一期 H09 报告头部（2026-10-10 17:00:00 ~ 2026-10-11 09:00:00）的结束时刻 09:00:00，两期首尾相接、无重叠、无遗漏；本期 run 实际时刻为 17:00，窗口右端取该时刻。
• 方法学记录：本期两处方法学改进——① 反馈拉取沿用脚本化落盘（_collect_feedback 直连 → JSON 落盘 → 程序化分类）；② 首次实测并固化 Logan 下载的 Basic Auth 路径（此前多次 401），使「Logan 可下载 / 不可下载」从主观判断变为可复算的二进制断言，本期即据此给出了 Android 可下载 vs HarmonyOS 零 Logan 的正向对照。

下一期 = 第227期 = 2026-10-12-H09（明天早上 09:00；本期为 17:00 正期，窗口 今日 17:00 ~ 明日 09:00）