Seetong · Report
Seetong 问题雷达 17：00 第 171 期
时间窗口：2026-09-09 09：00～17：00。
TL;DR 核心要点
- 本期没有达到 60 分筛选线且可独立升格的新问题。
- 🔴 监控不可见、设备离线与回放异常：多条反馈跨 Android、HarmonyOS 与不同终端型号出现，但与第 167、170 期的远程画面／回放链路重复，按 24 小时去重规则不重复深挖。
- 神策 NvrDeviceVideoPlayback 近 7 日仍持续触发；NvrMonitorFrameResult 的真实字段为性能字段，不存在 result／error_code，本期不外推失败率。
最近一个月 Top 问题
按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-09-09）。
| # | 问题（严重度降序） | 严重度 | 平台 | 版本 | 负责人 | 问题原因 |
|---|---|---|---|---|---|---|
| 1 | HarmonyOS 1.1.1.6 多功能受阻 1 期 | 100 | HarmonyOS | 1.1.1.6 | 唐胜、谭伟、张威 | HarmonyOS 1.1.1.6 在登录、设备状态、媒体连接多个表象上集中报障，当前可证实其落在共享 P2P/媒体状态链路附近，但缺少 Harmony 日志和端侧源码，尚不能锁定具体分支。 |
| 2 | 设备反复掉线、离线（详细分析） 1 期 | 100 | Android · HarmonyOS | 1.1.1.6 / 8.3.14.2 | 唐胜、张威 | 样本显示设备服务端已下发离线状态或NVR通道P2P建流失败，Android仅忠实消费SDK回调；现有神策缺失失败码，不能断言为单一Relay或客户端缺陷。 |
| 3 | 设备状态错判 / P2P 误报离线（详细分析） 1 期 | 90 | Android | 8.3.13.3 / 8.3.14.2 / 8.3.14.3 | 唐胜、张威 | SDK 在设备实际在线的情况下持续收到并上报 TPS_MSG_P2P_OFFLINE dev4gOnline=0，客户端 deviceOffline() 未充分去重即触发 UI 状态变更，导致用户看到"设备离线"但设备实际正常工作的矛盾现象 |
| 4 | Android 对讲通话，对方无法听到 1 期 | 75 | Android | 8.3.14.2 | 唐胜 | 用户点击对讲按钮后，App 无对讲行为日志，对讲上行链路未建立，可能为 UI 事件未正确触发 Native 对讲逻辑 |
| 5 | iOS 同一用户频繁掉线 1 期 | 75 | iOS | 8.3.14.3 | 欧阳荣 | 该用户设备端（摄像头固件/路由器）在有电有网条件下频繁离线，APP 端无主动触发逻辑，问题出在设备端或网络环境 |
| 6 | 人像/人体识别结果缺失（详细分析） 1 期 | 70 | Android · HarmonyOS | 1.1.1.6 / 8.3.12.5 | 许源、唐胜、谭伟、张威 | 目前仅确认两端均出现人像/人体结果缺失，代表设备支持该能力；缺少人形报警事件和配置回包，尚不能归因到 App、设备配置或设备端算法。 |
| 7 | HarmonyOS 实时预览不可用 7 期 | — | Android · HarmonyOS · iOS | 1.1.1.6 / 8.3.14.3 | 唐胜、许源、欧阳荣、18671356032 | （本期未收敛到单一根因） |
| 8 | NVR多通道视频加载异常（详细分析） 2 期 | — | Android | 8.3.14.2 | 张威、唐胜 | 证据更支持特定NVR通道切换后的播放帧输入/解码状态异常，而不是NVR离线、AddWatch失败或全局Relay故障。 |
| 9 | Android 设备回放不可用（详细分析） 1 期 | — | Android | 8.3.14.2 | 唐胜、张威 | 本期两条回放投诉不是同一已证实故障，其中一例当天录像索引为空，另一例是 TLS 建连失败后设备渲染超时；共同风险在于客户端未能区分并上报“无录像”与“链路失败”。 |
| 10 | Android设备离线（详细分析） 1 期 | — | Android | 8.3.14.2 | 许源、张威 | 该样本的设备在线状态由服务端列表与P2P离线回调共同判定为离线，证据指向设备侧连接或在线状态同步，未见客户端网络整体中断。 |
本期判断与证据
1．重复高风险问题：监控不可见、回放异常
- 反馈范围：窗口内可见的代表反馈包括 249181“看不了监控器了”、249192“无法打开视频”、249154“看回放视频卡顿，有声音”、249156“其中一个摄像头显示离线”，以及 HarmonyOS 上“摄像头看不到了”“打不开摄像头”等零散描述。覆盖 Android 8.3.8.3、8.3.14.2、8.4.0.5／8.4.0.6 与 HarmonyOS 1.1.1.8，终端涉及 WIKO、荣耀、华为等多个型号。
- 评分依据：按当前可见样本估计，反馈量 20／30，共性广度 30／30，业务关键度 40／40，合计约 90／100；但问题语义混合了实时预览、设备状态和回放，且与第 167、170 期已有链路重叠，标为重复高风险，不新增主问题任务。
- Logan 反馈 249181：Android 日志显示
PreviewPlayerView在启动预览后反复执行AutoResumePlay；LibImpl.addWatch返回add_watch_result=-1、portId=0、playing=false，但随后日志又显示ret:0与“视频播放中”。该日志未给出明确解码错误码，也未证明用户端最终是否看到画面，不能单独判定为客户端解码失败。 - Logan 反馈 249200：云端上传画面反馈对应日志中，设备列表接口返回成功且设备在线；
LibImpl.addWatch收到nResult=0，H.265 1920×1080 参数进入OpenStreamAgent与PlayAgent，随后出现PreviewPlayerView-onRecvFirstFrame。最终埋点记录isPreviewSuccess=true、isOnline=true、预览耗时 14827 毫秒，支持“该代表样本最终成功出图”，不能把本窗口所有画面反馈归因于统一客户端故障。 - 神策证据：
NvrDeviceVideoPlayback触发次数／用户数为：9 月 2 日 1266／5、9 月 3 日 842／3、9 月 4 日 1138／5、9 月 5 日 780／4、9 月 6 日 770／2、9 月 7 日 578／1、9 月 8 日 459／3、9 月 9 日 466／4。NvrMonitorFrameResult字段已核对为recv_frame_time、lag_rate、stream_type、channel_model、nvr_version等性能字段；按stream_type与channel_model的明细查询成功，未取得失败结果分布。 - 代码定位：Android 调用链为设备列表／预览入口 →
PreviewPlayerView.startPlay→LibImpl.addWatch→onMsgRspAddWatch→OpenStreamAgent／PlayAgent→onRecvFirstFrame；关键位置为Seetong-App-Android/.../device_list/view/VideoPlayerView.kt:411-416、808-900与.../sdk/impl/LibImpl.java:1468。日志中的add_watch_result=-1与后续ret:0并存，优先检查自动恢复、停止清理和首帧状态判定是否把“未建立端口”误标成播放中。 - 代码补充：共享播放 SDK 的
PC_OpenStream／PC_Play位于Seetong-CliCmpt-PlayCtrl-Sdk/PlayCtrl/PlayCtrl.cpp:206-272；iOS 对应Camera.mm:1296-1567，包括解码端口初始化、PC_OpenStream重试、PC_SetDecCallBack与PC_Play。当前没有与本窗口反馈一一对应的 iOS 解码失败日志。 - 结论：置信度为 🟡 中偏弱。现有证据支持“监控／回放异常反馈仍在持续，且存在自动恢复状态与用户感知不一致的信号”，但无法确认统一根因是设备端、录像数据、P2P 建流、解码还是渲染状态。
2．其他观察项与排除项
-102、-101及“请检查手机网络”提示约 82 条，跨品牌、版本、地区且未描述具体业务功能异常，按规则作为普遍网络问题排除。- 报警误报、没有报警或报警内容异常约 3 条；人像侦测误触发与报警噪音各有单点反馈，尚不足以形成跨用户共性，继续观察。
- 绑定、密码重置、硬盘错误、杂音、云端上传及其他短文本约 13 条，部分属于咨询或设备／配置问题；未达到 60 分，不进入本期主问题。
本期扫描全量与后续动作
| # | 关键词／类型 | 数量或范围 | 分类与处置 |
|---|---|---|---|
| 2 | 监控不可见、设备离线、无法打开视频、回放卡顿 | 约 8 条 | 🔴 重复高风险，沿用前期链路，不重复建任务 |
| 3 | 报警误报、报警为空、人像侦测异常 | 约 3 条 | 观察，证据不足 |
| 4 | 绑定、密码、硬盘、杂音、上传及其他 | 约 7 条 | 单点／配置／信息不足，观察或排除 |
已折叠 1 条普遍性网络问题（含-102/-101/-1002与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
- 下一步验证：继续为监控不可见与回放异常反馈补采 Android、iOS、HarmonyOS 各 1 条完整 Logan，并同时记录设备 SN、通道、查询时间段、录像类型、首帧耗时、
add_watch_result、nResult、PC_OpenStream／PC_Play返回值与最终画面状态。 - 代码验证：在 Android
VideoPlayerView的AutoResumePlay、clearDevice、onRecvFirstFrame及LibImpl.addWatch状态转换处补充会话 ID和最终渲染状态；iOS 继续核对Camera.mm:initDecodePort的重试分支。不得仅凭add_watch_result=-1定义为失败。 - 数据源状态：反馈模块成功返回 100 条并触及上限；心愿单返回 0 条；神策事件趋势与字段核对成功；Logan 代表样本 2 条下载成功但一条最终预览成功、一条未取得用户可见画面结论；无崩溃／ANR 类问题，未查询友盟；未查 TAPD；任务账本
captured为空，本期未新增任务。 - 待补证：窗口触及接口上限，无法保证 09：00～17：00 全量反馈都已取到；监控、回放、报警语义仍需按业务场景拆分，避免把实时预览与录像回放合并为单一故障。
- 下一期＝第 172 期＝2026-09-10-H09（明天早上 9：00）。
规则与口径
- 本期遵循 8 小时扫描窗口、24 小时重复去重、普遍网络问题排除和“神策字段先核对再分析”规则。
- 报告只保留脱敏后的反馈编号、终端与技术证据；不写入账号、手机号、IP、访问令牌或其他用户敏感信息。