Seetong · Report
🎯 Seetong 问题雷达 09:00 第78期
时间窗口：2026-07-29 01:00～09:00
TL;DR 核心要点
- 🔴 多端“手机端无回放”反馈聚集（严重度 70/100，置信度 🔴 弱）。2 名用户在 Android 8.3.13.3 与 Harmony 1.1.1.6 报手机端无录像回放；Android Logan 已证明设备具备 RemotePlayback=1111 权限，但未捕获到回放请求的失败回包。
- 🟣 -102/-101/-1002 约 40 条，属于已持续的普遍网络/relay 问题，按规则排除，不重复深挖。
- 反馈：Android 用户“电脑能看回放，手机看不见回放”（FB-239023）；Harmony 同一用户连续两次反馈“无录像回看视频”（FB-239020、FB-239019）。
最近一个月 Top 问题
按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-07-29）。
| # | 问题（严重度降序） | 严重度 | 平台 | 版本 | 负责人 | 问题原因 |
|---|---|---|---|---|---|---|
| 1 | 设备离线/P2P 通道失败（5 条 8h） 1 期 | 90 | — | 8.2.1.3 / 8.3.10.2 / 8.3.12.5 | 唐胜、许源、张威 | 用户设备 lastHeartTime 自 2026-07-03 02:25 起完全停止（用户尝试断电重启无效），客户端 TPS_MSG_P2P_OFFLINE 反复触发导致离线提示循环，但设备侧的物理掉线才是真实根因 |
| 2 | 回放入口/状态映射异常：无存储能力设备仍露出回放入口 1 期 | 70 | Android | 1.1.0.9 / 8.1.2.4 / 8.3.12.5 | 唐胜、张威 | 回放入口与录像状态 UI 主要依赖 sdRecordStu/权限，但未同步校验 NO_LOCAL_STOARGE 与 SDCardState=0，导致无存储能力设备仍可能暴露回放预期或状态显示异常。 |
| 3 | 在线看不到 1 期 | 70 | Android | 8.3.13.3 | 张威、唐胜 | NVR 通道预览链路在握手后立即被底层判为 PeerOffLine，APP 按现有逻辑只做快速重试，没有把通道离线与临时连接抖动区分开，最终表现为“在线看不到”。 |
| 4 | 多端手机端无回放 1 期 | 70 | Android | 1.1.1.6 / 8.3.13.3 | 冉博麟、李国涛 | （本期未收敛到单一根因） |
| 5 | 设备离线/掉线后无法预览 1 期 | 70 | Android · iOS | 1.1.1.6 / 8.2.2.1 / 8.3.13.3 | 唐胜、张威 | 设备预览链路在收到 TPS_MSG_P2P_OFFLINE 后直接走离线兜底分支，UI 进入“该设备不在线”，而自动恢复逻辑又被离线判断短路，导致用户感知为“掉线后无法再连上”。 |
| 6 | 录像回放缺失 — 无 SD 卡的设备被直接引导云存购买(产品设计问题) 1 期 | 65 | Android · iOS | 8.3.12.5 / 8.3.13.3 / 8.3.13.4 | 张威、唐胜、陈宝旺 | 无 SD 卡 + 未开通云存的设备,在 NVR 回放协议响应无效时直接跳转云存购买页,没有任何"为什么没录像"的说明,用户感知是"以前能看现在不能" |
| 7 | 设备二维码模糊/找不到（3 条 8h） 1 期 | 65 | — | 8.3.12.5 | 待定 | （本期未收敛到单一根因） |
| 8 | 鸿蒙系统监控掉线（3条同用户） 2 期 | 60 | Android | 1.1.0 / 1.1.0.9 / 1.1.1.0 | 许源、陈宝旺、张威、唐胜 | 鸿蒙OS对App后台服务管控更严格，App进程被系统强制回收后，设备状态无法实时刷新，导致首页设备列表不更新；杀后台重启App后状态恢复 |
| 9 | Android NVR 回放/预览偶发不出图，断开重连后恢复 1 期 | 60 | Android | — | 唐胜、张威 | NVR 回放/预览链路在首次 addWatch + 查询录像时间片 阶段存在瞬时失败，UI 侧又把多类失败统一收敛为空/超时，导致用户感知为“不出图，重连才恢复”。 |
| 10 | Android 监控预览 addWatch 失败 + 10 秒循环重试 1 期 | 60 | Android | 8.3.13.3 | 唐胜 | Android 端 LibImpl.startPlay 把 addWatch 返回的 P2P 断连错误码（-1）通过 if (ret == SDK_CONSTANT.ERR_P2P_DISCONNECTED) ret = 0; 强制归零，导致上层误以为流启动成功，进入 10 秒循环重试；用户看到的"长时间缓冲"实质是 10 秒 × N 次的循环重试视觉感受 |
🔴 问题 1：多端手机端无回放（详细分析） ｜ 负责人：冉博麟、李国涛
现象与覆盖范围
- 反馈：Android 用户“电脑能看回放，手机看不见回放”（FB-239023）；Harmony 同一用户连续两次反馈“无录像回看视频”（FB-239020、FB-239019）。
- 覆盖：2 名用户、Android 8.3.13.3（Redmi 2407FRK8EC）与 Harmony 1.1.1.6（HUAWEI VYG-AL00）。同一 Harmony 用户的两条重复提交按单个有效样本计。
- 严重度：70/100。反馈量 20/30（3 条）；共性 20/30（回放功能、2 平台）；关键度 30/40（录像回放）。
多源证据
- 神策，部分可用：
NvrDeviceVideoPlayback字段定义仅含设备、通道、连接与耗时等信息，没有error_code/result，不能做失败码分布。近 7 天触发用户从 7 月 22 日的 2 人降至 7 月 26 日的 1 人，7 月 27～29 日为 0；未见平台级回放事件放量。该事件未覆盖本期用户操作或未上报，不能据此否定反馈。 - Logan，FB-239023：设备
26245848已返回RemotePlayback="1111"、P2PReplay与replay_support_sec能力，说明权限/能力协商完成；随后在 08:43、08:56、08:57 对CH-1/CH-2执行pauseNvrReplay → stopNvrReplay，返回ret=[0]。日志中未见TPS_MSG_RSP_NVR_REPLAY失败回包或错误码，无法确认是“列表无录像”、播放启动失败还是用户退出。 - 数据源失败模式：神策核心查询成功，但没有失败码字段；Logan 可下载但没有覆盖用户所述失败瞬间。故本期为证据降级，不能把单一代码风险写成确定根因。
代码定位与根因判断
- Harmony 调用链：
DynamicGridPage.ets:378的backPlayClick()→Router.push(Routes.ReplayPageNew)→ReplayPage.ets初始化。 - 关键分支：
ReplayPage.ets:420-446仅在低功耗设备唤醒分支注册TPS_MSG_P2P_CONNECT_OK并调用initDate()；普通设备分支直接initDate()，若进入页时设备离线，后续上线没有回放列表重试。 - SDK 回调锚点：
napi_init.cpp:825-851收到TPS_MSG_RSP_NVR_REPLAY后，bHaveAudio == 0、nResult != 0或端口非正都直接返回失败。当前日志无此回包，需先补齐上报，不能判断设备端还是页面状态机导致。 - 结论：Harmony 既有“设备上线后不重试回放”的风险路径，能解释部分空态；但 Android 同期样本表明问题不宜仅归因 Harmony。本期根因置信度：🔴 弱。
建议下一步
- 分配给：Android、Harmony 回放模块负责人。
- 优先处理：在 Android/Harmony 回放请求与
TPS_MSG_RSP_NVR_REPLAY回调记录devId/channel/nResult/bHaveAudio/请求时机；Harmony 普通设备路径复用上线监听并在回调后重试initDate()。 - 验证方法：使用 FB-239023 的四通道设备，在应用重启、设备短暂离线再上线、切换通道三种场景验证“列表可见 + 可起播”；同步确认同一设备电脑端与手机端的录像索引是否一致。
本期扫描全量
| 关键词 | 反馈数 | 分类 | 处置 |
|---|---|---|---|
| 手机端无回放 | 3 | 🔴 进雷达 | 本期详细分析 |
| 设备离线、登录、报警、音频等单点反馈 | 约 18 | 🟢/🟡 | 样本不足，未进雷达 |
已折叠 1 条普遍性网络问题（含-102/-101/-1002与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
下一期 = 第79期 = 2026-07-29-H17（今天 17:00）
本消息由 Seetong小助手 自动生成，欧阳荣 监督发布。