Seetong · Report
🎯 Seetong 问题雷达 17:00 第215期
时间窗口：2026-09-30 09:00 ~ 17:00
TL;DR 核心要点
- 🔴 升级后回放能力整体退化（时间条 + 切换通道 + 回放卡顿/黑屏 + 人形录像缺失）（严重度 85 / 100，置信度 强）
- 🟠 报警消息点击无响应 / 人形报警联动缺失（严重度 62 / 100，置信度 中）
- 现象描述：升级到 8.4.1.6 后，回放相关能力出现多点退化——① 回放时间条不好用/遮挡屏幕；② 切换通道时播放进度不再接续，跳到别的时间；③ 回放卡顿/卡死/黑屏；④ 报警消息里的人形侦测只有抓拍图、没有视频录像，回放找人困难。
🔴 问题 1：升级后回放体验整体退化（详细分析）
1. 现象与覆盖范围
- 现象描述：升级到 8.4.1.6 后，回放相关能力出现多点退化——① 回放时间条不好用/遮挡屏幕；② 切换通道时播放进度不再接续，跳到别的时间；③ 回放卡顿/卡死/黑屏；④ 报警消息里的人形侦测只有抓拍图、没有视频录像，回放找人困难。
- 涉及反馈：至少 6 条独立反馈（254053 / 254032 / 254044 / 254043 / 254036 / 254091）
- 设备跨度：Android（HONOR NTH-AN00 / OPPO PKZ110 / Liantong VP002）+ iOS（iPhone）
- 版本：均为 8.4.1.6（当前在产主力版本）
- 网络：含 4G 与 WiFi，非单网络
- 严重度评分：85/100（反馈量 20 / 共性 25 / 关键度 40）
- 反馈量：6 条独立反馈（>5 条 → 20 分）
- 共性广度：跨 2 平台 + 多机型 + 多地区（≥2 维 → 25 分，未达 3 维满档）
- 业务关键度：回放 = 30，叠加"报警→回放"核心链路，按设备录像回溯计 40
2. 神策证据（核心数据源）
MonitorWatchStep近 7 天（9/24 ~ 9/30）：触发次数 388968→417000→323471（9/30 至 17:00 已 323471，占比合理）NvrDeviceVideoPlayback近 7 天：点击量极低（每日 1~4 次），说明该事件埋点覆盖面不足，回放主链路的埋点未命中 NVR 回放场景 → 回放链路的线上可观测性本身是缺口- 神策
query_segmentation_report（NvrMonitorFrameResult+by_fields:["date"]）报COMMON-R-131-1 wrong field expression: date；改用query_event_count兜底成功，未继续重试（遵守"同 query 失败 ≤3 次即降级"） - 趋势判断：回放类反馈集中在 8.4.1.6 版本，且与 9/29 第 212/214 期"回放期间息屏"线索同版本延续 → 疑似同一版本的回归域，而非新增孤立问题
3. Logan 关键日志（核心数据源）
- 反馈 ID：254029（用户 18355760996，HONOR NTH-AN00，Android 8.4.1.6，附 ZIP + Logan）
- Logan 规模：3026257 字节 / 320117 行
- 错误码统计（本次日志）：
-102: 304 次、-101: 220 次、ssl_connect: 6 次、EXCEPTION: 202 次 - 关键上下文：
funclib: p2p!!: Id=xxx p2p OpenP2P uTryP2PTimeout:4, szRelayIp=...→ P2P 打洞 4 秒超时后走中转pgInitialize success ... status:P2（P2P 初始化成功）SignalingExchange: Send offer ... "always_use_tcp":1,"disable_p2p":1→ 该会话被强制 TCP 中转（禁用 P2P）- 设备能力位：
RemotePlayback="11111111111111111111111111111111"（32 通道回放能力齐全） Ipcs_stat / streamstat / IpcAbility1多设备状态串完整- 引文（脱敏）：
[L1113] p2p OpenP2P uTryP2PTimeout:4,szRelayIp:type=0&load=21&addr=shrelay16.s5.seetong.com:8443;...[L2125] Send offer: {... "always_use_tcp":1,"disable_p2p":1 ...}- 结论：Logan 里没有崩溃栈，主因不是 App 崩溃，而是回放链路在"P2P 超时 → 强制 TCP 中转"路径下的取流/解码表现**——这正是"回放卡/卡死"的现场特征。
- 第二份 Logan（反馈 254036，iOS 回放黑屏）：113302 字节 / 15434 行，错误仅
-101: 3、EXCEPTION: 1，回放启动阶段无致命错误，属"能连上但出图异常"，与"黑屏"描述一致（解码/首帧路径，而非连接路径）。
4. 问题 1 代码定位（详细）
- 涉及模块：
Seetong-App-Android（回放/报警），跨端共用Seetong-CliCmpt-PlayCtrl-Sdk - 关键类：
com.seetong.app.seetong.tools.MotionAlarmManager（MotionAlarmManager.java:27）——人形/移动侦测报警管理，直接对应"人形报警只有抓拍无录像"com.seetong.lib_base.device.PlayerDevice（lib_base/src/main/java/com/seetong/lib_base/device/PlayerDevice.java）——回放能力位/通道状态PlaybackPageRouter（app/.../ui/utils/PlaybackPageRouter.java）——回放页路由与入参（对应"切换通道跳时间"）- 调用链（推断锚点）：
报警消息点击→PlaybackPageRouter（携带 alarmTime）→ 回放页 seek →PlayerDevice取流 →PlayCtrl-Sdk解码 - 关键分支：切换通道时若沿用上一次的
alarmTime而未重新对齐该通道的时间轴，会出现"跳转到别的时间"（对应 254053 / 254032 反馈） - 修复方向锚点：
MotionAlarmManager：确认升级后"报警仅抓拍"是否切断了录像关联字段（人形报警 → 录像片段映射）PlaybackPageRouter/ 回放页：切换通道时重置并重新计算时间轴基准，而不是继承上一通道进度- 回放时间条：核对 8.4.1.6 新时间条的遮挡/精度改动（对应 254032"没有之前好用"、254017"不能精确到秒"）
5. 问题 1 根因结论
- 置信度：🟢 强
- 一句话根因：8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
- 关键证据链：Logan（无崩溃栈 + 强制 TCP 中转 + 能力位正常）+ 神策（
MonitorWatchStep量级正常、回放专用埋点缺失）+ 多用户同版本反馈，三者互相印证"版本回归"而非"网络个例"。
6. 问题 1 建议下一步
- 分配给：Android 回放负责人 + iOS 回放负责人（跨端）
- 优先处理项：
- 核对 8.4.1.6 回放时间条与通道切换的改动 diff，确认进度继承 bug
- 核实"人形报警只出抓拍图、无录像"是否为该版本录制/关联逻辑变更
- 验证方法：以 254029（HONOR NTH-AN00）为回归用例，覆盖"P2P 超时→TCP 中转"场景下的回放首帧与拖动稳定性
🟠 问题 2：报警消息点击无响应 / 人形报警联动缺失（详细分析）
1. 现象与覆盖范围
- 现象描述：点开报警信息有时没有反应；人形侦测推送不及时/需次日才提醒；报警消息缺少直达回放入口。
- 涉及反馈：254031（vivo V2405A / 衡水 / 8.4.1.6）、心声 5006（vivo V2425A / 哈尔滨 / 8.3.14.2）、心声 4998（iPhone 13 / 贵州 / 8.4.1.6）
- 严重度评分：62/100（反馈量 20 / 共性 12 / 关键度 30）
- 反馈量：反馈 + 2 条心声指向同一诉求（3-5 条 → 20）
- 共性广度：跨 2 机型 + 2 版本（2 维 → 20，实际按 12 折算，因样本偏少）
- 业务关键度：报警 = 30
2. 神策证据
AlarmMessage事件未在本次窗口取到有效分组（沿用降级：不作为强证据）- 与问题 1 共享
MonitorWatchStep趋势：量级正常，说明"进入回放"动作本身有量，问题在"报警→回放"的跳转响应 - 置信度受限：报警类埋点在该窗口未单独命中，本条置信度为中
3. Logan 关键日志
- 反馈 254031 提供 Logan（vivo V2405A）：日志内未见明显异常栈
- 反馈 5006 / 4998 无 Logan（心声单，无 logan 链接）
- 结论：本条以用户描述 + 心声诉求为主证据，Logan 佐证"无崩溃"
4. 问题 2 代码定位
- 涉及模块：
Seetong-App-Android报警模块 - 关键类：
MotionAlarmManager（MotionAlarmManager.java:27）——报警触发与管理 - 调用链（推断）：
推送到达→AlarmMessageReceiver→MotionAlarmManager→ 唤起回放/预览页 - 修复方向锚点：报警消息点击的响应态（loading/去重/防抖）与"直达回放"入口补齐
5. 问题 2 根因结论
- 置信度：🟡 中
- 一句话根因：报警消息点击链路缺少可靠响应与直达回放入口；人形推送时效受制于触发策略，与版本改动叠加放大了体感缺失。
- 关键证据链：用户描述（254031）+ 心声诉求（4998/5006）+ Logan 无崩溃
6. 问题 2 建议下一步
- 分配给：报警链路负责人
- 优先处理项：报警消息点击响应的防抖与状态提示；评估"人形报警直达回放"对齐 4998 心声
- 验证方法：报警推送 → 点击 → 回放页的端到端耗时埋点
本期扫描全量（全部沉淀到知识库）
| # | 关键词 | 反馈数 | 分类 | 处置 |
|---|---|---|---|---|
| 1 | 回放卡/卡死/黑屏/时间条/切换通道 | 6 | 🔴 进雷达 | 详细分析见上 |
| 2 | 报警点击无响应/人形联动 | 3 | 🟠 进雷达 | 详细分析见上 |
| 3 | -102 / -101 网络类 | 155+ | 🟣 网络问题 | 已排除（普遍类） |
| 4 | 人工客服无人接/联系客服 | 4 | 🟢 用户操作 | 已排除（非功能缺陷） |
| 5 | 心愿单建议（新增功能类） | 34 | 🟤 心愿单 | 已排除 |
| 6 | 设备离线/打不开/连不上（单设备） | 5 | 🟡 配置问题 | 已排除 |
数据源状态汇总
| 数据源 | 状态 | 说明 |
|---|---|---|
| 反馈接口 | ✅ 正常 | total=200，接口触及上限，实际 ≥ 200 |
| 心愿单接口 | ✅ 正常 | total=50 |
| 神策（query_event_count） | ✅ 正常 | MonitorWatchStep / NvrDeviceVideoPlayback 取数成功 |
| 神策（query_segmentation_report） | ⚠️ 降级 | COMMON-R-131-1 wrong field expression: date（by_fields 用法不支持），改 query_event_count 兜底 |
| Logan（Android 254029） | ✅ 正常 | 3.0MB / 32 万行，错误码 -102:304 -101:220 EXCEPTION:202 |
| Logan（iOS 254036） | ✅ 正常 | 113KB / 1.5 万行，错误码 -101:3 EXCEPTION:1 |
| 友盟 | ⏭️ 未查 | 本轮问题非崩溃/ANR 类，按规则跳过 |
| TAPD | ⏭️ 未查 | 无用户引用单号，按规则跳过 |
待补证
- 回放专用埋点（
NvrDeviceVideoPlayback）覆盖面不足，需推动补齐"回放启动/首帧/拖动"三个关键节点的埋点 - 报警类事件（
AlarmMessage）本期未单独命中，下次 run 尝试query_sql直查原始表 - 254029 的 ZIP 附件未解压比对（仅用 Logan）；如需要可补一次 ZIP 内埋点截图核对
- 8.4.1.6 回放改动的代码 diff 待研发确认（Stage 3 为路径级定位，非行级定论）
下一期 = 第216期 = 2026-10-01-H09（明天早上 9:00）