🎯 Seetong 问题雷达 09:00 第247期

🔴 问题 1：HarmonyOS 1.1.2.3 视频、录像与回放链路多点失效

1. 现象与覆盖范围

• 258795：HarmonyOS 6.0、HUAWEI ALN-AL80、山东潍坊。登录后设备页下滑出现卡顿，点击设备预览后提示“网络断开”，用户明确写明“必现”，卸载重装仍无效。
• 258821：HarmonyOS 1.1.2.3、HUAWEI TLR-AL00、辽宁沈阳。用户反馈“大门回放不出来任何东西”。
• 258774：HarmonyOS 1.1.2.3、HUAWEI BLK-AL80、上海。用户反馈“有人不能录像经常有”，指向人形事件发生时不录像。
• 258743：HarmonyOS 1.1.2.3、HUAWEI SUP-AL90、浙江温州。用户反馈“监控怎么从手机上看不到了”，手机端核心查看能力不可用。
• 以上为 4 名独立用户，覆盖 4 个机型、4 个省级地区，均集中在同一版本。它们可能不是同一个根因，但共同落在“预览 → 录像 → 回放 → 手机查看”主链路，不能作为普通网络噪声或单条咨询忽略。
• 严重度评分：90 / 100。反馈量 20（4 名独立用户）、共性广度 30（HarmonyOS、同一版本、4 个机型、4 个地区）、业务关键度 40（实时查看与录像取证均为核心能力）。
• 去重判定：与既有 HarmonyOS 实时预览和回放大范围不可用任务同域，沿用 T-20260926-170258-2226，不重复创单；本期新增 1.1.2.3 的多机型聚集证据。

2. 神策证据

• 2026-10-22 截至 09:07，HarmonyOS 1.1.2.3 的 DeviceVideoPlayback 为 167,628 PV / 92,285 UV，其中 error_code=200 为 161,701 PV，失败约 5,927 PV，失败率 3.54%。
• 同一时点的 error_code 明细查询返回 5,925 条失败，和总数口径相差 2 条，属于实时入库差异。失败主要来自 SA106006 3,725 条、SA106012 531 条、SA106008 530 条、SA106010 431 条、SA106001 382 条。
• 近 7 天同版本播放失败率依次为 5.471%、4.064%、3.370%、2.878%、2.600%、2.585%、3.536%。10 月 22 日为未完整日，不能直接与前六个完整日等同，但从 10 月 21 日的 2.585% 回升到当前 3.536%，与本窗口用户聚集方向一致。
• MonitorFrameResult 在 HarmonyOS 1.1.2.3 下没有查询到可用记录，因此预览首帧成功率无法按该版本量化。这是观测缺口，不等于预览未失败；258795 的预览故障仍需补埋点。
• 反馈平台 clientId 尚未映射到神策 distinct_id，不能把上述大盘失败逐条归到 4 名反馈用户，神策只用于判断同版本风险背景。

3. Logan 与附件

• 258795、258821、258774、258743 均未提供 Logan，无法定位具体失败返回值、连接类型、设备固件和首帧时间。
• 258795 写明“必现”且卸载重装无效，提供了较强的现象证据，但当前只能排除“用户误操作”这一弱解释，不能区分：
• ts_AddWatchEx 同步返回失败；
• P2P／relay 已建立但长时间无首帧；
• 设备本身离线或网络不可达；
• 播放组件或页面状态错误覆盖；
• 设备无录像、存储异常或事件列表查询失败。

4. 代码定位

• HarmonyOS 原生回放页：seetong-app-harmony/feater/playDevice/src/main/ets/view/replay/ReplayPage.ets:153-155。isOffline 只声明为 false，注释明确“目前未赋值”；全文件仅在 :3887 读取它展示离线态，没有发现写入路径。
• 快速预览组件：seetong-app-harmony/feater/playDevice/src/main/ets/view/AutoPlayDeviceView.ets:21-43。页面展示后直接调用 playDevice，但忽略返回的布尔值，也没有注册 call 回调、错误态或首帧超时；deviceFirstFrameEvent 只负责隐藏进度圈，若首帧不到，页面可以永久停留加载态。
• 播放服务：seetong-app-harmony/feater/playDevice/src/main/ets/service/DeviceServiceImpl.ets:5493-5548。ts_AddWatchEx 的具体返回值被折叠成 ret == 0，上层拿不到 -1/-6/-10 等错误语义。
• 统一播放入口：seetong-app-harmony/feater/playDevice/src/main/ets/utils/ViewPageUtil.ets:270-298。结果 -1 的提示被注释掉，未知错误分支也不展示任何提示，因此实际失败可能表现为静默、长转圈或被其他网络提示覆盖。
• 回放页的数据加载另有明确超时分支，例如 ReplayPage.ets:758-978 与 :1240-1309；但当前没有 4 名用户的日志，无法证明“不录像”和“回放为空”由这些分支触发。

5. 根因结论

• 置信度：现象 🟢 强；根因 🔴 弱。
• 一句话根因：当前证据只能确认 HarmonyOS 1.1.2.3 在核心视频链路上出现跨用户聚集，尚不能把四种症状归为同一根因；代码侧明确存在“播放返回值被折叠、错误提示分支缺失、离线状态从未赋值、预览首帧缺少超时兜底”的观测与状态处理缺口。
• 明确不下的结论：不把问题直接归因为 4 名用户手机网络差，也不把“不录像”与“回放为空”未经证据合并成同一设备故障。

6. 建议下一步

• 分配给：HarmonyOS 播放链路负责人，设备服务与 KMP 回放负责人配合；沿用任务 T-20260926-170258-2226，状态保持 P1 / captured。
• 首先补齐端到端可观测性：每次预览和回放生成 requestId，统一记录 devId、设备固件、网络类型、ts_AddWatchEx 返回值、连接类型、首帧耗时、onError 和退出原因；MonitorFrameResult 必须覆盖 HarmonyOS 1.1.2.3。
• 修复错误透传：playDevice 返回具体错误码而非布尔折叠结果；-1/-6/-10、超时和无首帧必须进入明确失败态，并在 10 秒内提供重试入口，不得永久转圈。
• 为 isOffline 建立唯一写入源：只由设备在线态更新，不能把一次预览失败永久改写成离线，也不能让离线提示因状态从未赋值而永不出现。
• 将“无录像”“存储卡异常”“NVR 事件列表超时”“设备离线”拆成不同提示和埋点，禁止统一显示为“网络断开”。
• 回访 13508965818、18241935168、13853977052、18658717811，索取设备型号、固件、SN、发生时刻及 Harmony 日志；分别在华为 6.0 与 5.x、Wi-Fi 与移动网络下连续预览、录像、回放各 20 次。

🟠 问题 2：Android KMP 卡回放缩放时游标回跳并产生时间状态错位 ｜ 负责人：陈宝旺、谭伟

1. 现象与覆盖范围

• 258835：Android 8.4.1.6、Xiaomi 23116PN5BC、山东潍坊，反馈“回放放大时间的时候，光标指示条乱跳”，同时提供 Logan 与 OBS 日志。
• 用户不是泛指卡顿。日志明确记录了缩放后游标从 08:52:15 回跳到 08:41:44，随后拖动时显示时间继续变化，而状态时间停留在旧值。
• 严重度评分：70 / 100。反馈量 10（1 名独立用户）、共性广度 30（Android、8.4.1.6、具体机型、山东地区）、业务关键度 30（历史录像定位属于核心取证链路）。
• 去重判定：任务账本已有 T-20260922-170415-9496“排查 Android 卡回放拖动卡顿与时间跳转异常”，其下一步正是核对 stateTimeSec 与 timeSec 偏差；本期是该状态的同域复现，更新既有任务，不另建重复任务。

2. 神策证据

• 2026-10-22 截至查询时，Android 8.4.1.6 的 DeviceVideoPlayback 约 2,477,470 PV / 1,227,557 UV，成功 2,350,156 PV，失败 127,314 PV，失败率 5.139%。
• 10 月 16 日至 21 日的完整日失败率分别为 3.944%、4.125%、4.103%、4.010%、4.012%、4.065%。10 月 22 日为未完整日，当前 5.139% 可用于风险提示，但不能直接解释为整天恶化。
• DeviceVideoPlayback 只能覆盖播放启动错误和大盘失败，不能度量“游标视觉位置跳变”。258835 在进入回放时上报的 errorCode=200，说明播放链路本身成功，而用户看到的是页面状态同步错误；因此这不是“神策失败率未升高所以用户无问题”的反证。
• 当前没有独立的 timeline_zoom_state_mismatch 指标，无法估算该交互问题在全部缩放用户中的发生率。

3. Logan 关键日志

• 反馈 ID：258835。Logan 共 8,556 行、210,869 字节，另有 3 个 OBS logcat 附件。
• 08:54:48.145：KMPTimelineView.getCurrentScale callback, scale=1.0。
• 08:54:48.541：首次调整后 scale=10.0。
• 08:54:49.992：DeviceVideoPlayback errorCode=200，说明首次进入回放成功。
• 08:54:59.137-08:54:59.962：连续缩放期间，页面多次收到 onTimeChanged timeSec=31935，对应 08:52:15；日志中的 stateTimeSec 也是 31935。
• 08:55:02.084 至 08:55:02.590：再次缩放后，onTimeChanged 突然变成 timeSec=31304，对应 08:41:44；此时 stateTimeSec=31304/31305。相对上一位置回跳 631 秒，即 10 分 31 秒。
• 08:55:03.808-08:55:03.946：用户开始拖动，时间从 31335 连续变化到 31364，但 stateTimeSec 一直停在 31306，形成 29～58 秒的实时偏差。
• 08:55:04.005：onTimeSelected timeSec=31375；08:55:04.309 才把 stateTimeSec 更新到 31375，并执行 seekReplay date=20261022084255。
• 日志中的“回跳”和“显示值与状态值分离”与用户“光标指示条乱跳”的描述一致，不是主观误判。

4. 代码定位

• seetong-kmp/modulePlayback/src/commonMain/kotlin/com/seetong/moduleplayback/page/playback/card/CardPlayBackPageTimeline.kt:65-76：每次构建 TimelineConfig 都把 ctx.card.currentTimeSec 下发给原生时间轴。
• 同文件 :81-90：onTimeChanged 只更新 currentTimeText，没有同步更新 currentTimeSec。因此拖动和缩放期间，原生时间轴的真实位置持续前进，而共享状态仍保留上一次松手时的时间。
• CardPlayBackPageLogic.kt:191-218：applyZoomToTimeline 先更新 portraitTimelineScale 和 fullscreenTimelineScale，再调用原生 applyScale。比例状态变化会触发页面重组，而重组携带的 currentTimeSec 是旧快照。
• Seetong-App-Android/.../KMPTimelineView.kt:125-158：updateConfig 从配置中重新读取 currentTimeSec，随后无条件 center(currentTimeSec, false)。
• KMPTimelineView.kt:228-231：setScale 又使用传入的 anchor 重新居中。配置更新与原生缩放方法之间没有版本号或交互锚点保护，旧状态可以覆盖新位置。
• 调用链可归纳为：拖动或播放推进原生游标 → onTimeChanged 仅更新文本 → 点击缩放修改 scale 状态 → Kuikly 重组并重发旧 currentTimeSec → updateConfig 强制居中到旧时间 → 游标回跳。

5. 根因结论

• 置信度：现象 🟢 强；根因 🟢 强。
• 一句话根因：时间轴在交互过程中由原生控件持有最新时间，但页面共享状态只更新显示文本；缩放触发重配置时又把旧的 currentTimeSec 下发给原生并重新居中，导致游标回跳与状态时间滞后。
• 关键证据链：用户现象与 Logan 的 631 秒回跳完全对应；代码中 onTimeChanged 不写 currentTimeSec、缩放会触发配置重组、原生 updateConfig 无条件居中到配置时间，三段形成闭合链路。

6. 建议下一步

• 分配给：Android KMP 卡回放负责人；沿用任务 T-20260922-170415-9496，状态保持 P1 / captured。
• 缩放只更新 scale，不要用完整的旧 TimelineConfig 重新覆盖原生时间位置；若框架必须重组，配置必须使用当前原生游标或递增的交互版本号。
• onTimeChanged 同步更新一个轻量 interactiveTimeSec，与最终提交的 currentTimeSec 分离；缩放、旋转、全屏恢复都读取交互锚点，松手 onTimeSelected 后再原子提交最终 seek 时间。
• 在原生 KMPTimelineView 中增加 configVersion/gestureEpoch；若配置版本早于当前缩放或拖动操作，直接丢弃旧时间锚点。
• 回归覆盖播放中放大／缩小、拖动中缩放、连续点击 10 次、00:00 与 24:00 边界、倍速、切通道、前后台、横竖屏和枪球双轨。每个场景断言游标时间单调变化、显示值与状态值偏差不超过 1 秒、缩放前后锚点偏差不超过 1 秒。
• 新增埋点记录 beforeZoomTimeSec、afterZoomTimeSec、stateTimeSec、scale、gestureSeq，用于后续监控同一次缩放是否出现超过 5 秒的异常回跳。

本期扫描全量

已折叠 1 条普遍性网络问题（含 -102/-101/-1002 与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如 Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。

反馈接口返回 total=96 / fetched=96 / complete=true / pages=2。上表按主问题唯一归类，合计 96 条；同一用户短时重复提交不放大反馈量。

心愿单亮点

数据源状态与待补证

• 反馈平台：✅ 正常。total=96 / fetched=96 / complete=true / pages=2，时间窗口内无接口截断。
• 心愿单：✅ 正常。total=16 / fetched=16 / complete=true。
• 神策：✅ 主查询成功。获得 HarmonyOS 1.1.2.3 与 Android 8.4.1.6 的 DeviceVideoPlayback 错误码和近 7 天趋势；首次三条 SQL 因字段限定写成 event.error_code 失败，核对事件字段后改用 error_code 重跑成功，未使用失败结果生成结论。
• Logan：⚠️ 部分可用。258835 的 Logan 与 OBS 完整；问题 1 的 4 名 HarmonyOS 用户全部未提供 Logan，根因只能定为弱置信度。
• 代码仓：✅ Android、HarmonyOS、seetong-kmp 均在标准路径。已定位 Android 时间轴状态覆盖链路，以及 HarmonyOS 播放返回值、离线态和首帧错误处理缺口。
• 友盟：⏭️ 未调用。本期进入雷达的问题是功能不可用与时间轴状态错误，不是崩溃或 ANR。
• TAPD：⏭️ 未调用。两项均有任务账本中的既有捕获任务，先完成日志补齐与本地复现，不以历史 Bug 搜索替代根因验证。
• 待补证：HarmonyOS 4 名用户需要设备 SN、固件、网络类型和发生时刻日志；258835 需要补充不同缩放倍数与枪球双轨的录屏，以验证 631 秒回跳是否与时间和缩放比例变化呈固定关系。

下一期 = 第248期 = 2026-10-22-H17.md（今天下午 17:00；窗口 今日 09:00:32～17:00）