Seetong · Report

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

时间窗口：2026-07-27 01:00 ~ 09:00（过去 8h）

📌TL;DR 核心要点

🔴 问题 1：Android 监控预览 addWatch 返回 -1 + 10 秒循环重试仍不出图（严重度 60 / 100，置信度 🟡 中）
🟠 问题 2：vivo 设备反复 TPS_MSG_P2P_OFFLINE + dev4gOnline=-1 设备无法恢复（严重度 60 / 100，置信度 🟡 中）
现象：用户反馈"监控一直在缓冲中，长时间看不到监控图像"（反馈 ID：238549）

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-07-27）。

#	问题（严重度降序）	严重度	平台	版本	负责人	问题原因
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	回放入口/状态映射异常：无存储能力设备仍露出回放入口 2 期	70	Android	1.1.0.9 / 8.3.12.5 / 8.1.2.4	唐胜、张威	回放入口与录像状态 UI 主要依赖 sdRecordStu/权限，但未同步校验 NO_LOCAL_STOARGE 与 SDCardState=0，导致无存储能力设备仍可能暴露回放预期或状态显示异常。
3	在线看不到 1 期	70	Android	8.3.13.3	张威、唐胜	NVR 通道预览链路在握手后立即被底层判为 PeerOffLine，APP 按现有逻辑只做快速重试，没有把通道离线与临时连接抖动区分开，最终表现为“在线看不到”。
4	设备离线/掉线后无法预览 1 期	70	Android · iOS	1.1.1.6 / 8.2.2.1 / 8.3.13.3	唐胜、张威	设备预览链路在收到 TPS_MSG_P2P_OFFLINE 后直接走离线兜底分支，UI 进入“该设备不在线”，而自动恢复逻辑又被离线判断短路，导致用户感知为“掉线后无法再连上”。
5	录像回放缺失 — 无 SD 卡的设备被直接引导云存购买(产品设计问题) 1 期	65	Android · iOS	8.3.12.5 / 8.3.13.3 / 8.3.13.4	张威、唐胜、陈宝旺	无 SD 卡 + 未开通云存的设备,在 NVR 回放协议响应无效时直接跳转云存购买页,没有任何"为什么没录像"的说明,用户感知是"以前能看现在不能"
6	设备二维码模糊/找不到（3 条 8h） 1 期	65	—	8.3.12.5	待定	（本期未收敛到单一根因）
7	Android NVR 回放/预览偶发不出图，断开重连后恢复 1 期	60	Android	—	唐胜、张威	NVR 回放/预览链路在首次 addWatch + 查询录像时间片阶段存在瞬时失败，UI 侧又把多类失败统一收敛为空/超时，导致用户感知为“不出图，重连才恢复”。
8	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 次的循环重试视觉感受
9	iOS 8.3.12.6 灰度放量新症状 4 期累计扩散 1 期	60	iOS	8.3.12.5 / 8.3.12.6	欧阳荣、谭伟	iOS 8.3.12.6 客户端第三方微信登录→绑定手机号→触发滑动验证→重发短信验证码的全链路（BindNewPhoneOrEmailViewController.m:317-378）均正常工作，服务端短信下发接口返回 200 成功，根因在第三方短信通道商下发链路（运营商拦截 / 短信网关失败 / 用户手机短信拦截），非客户端代码问题。
10	iOS 8.3.4.3 老版本"网络正常情况下掉线 + 语音提示循环" 1 期	60	iOS	8.3.12.5 / 8.3.4.3 / 8.3.7	待定	iOS 8.3.4.3 老版本在网络瞬断时，"网络连接正等待"语音提示无频率限制，导致循环播放；神策 7-1 数据未显示掉线激增，非全量问题。

🔴 问题 1：Android 监控预览 addWatch 失败 + 10 秒循环重试（详细分析）｜负责人：唐胜

1. 现象与覆盖范围

现象：用户反馈"监控一直在缓冲中，长时间看不到监控图像"（反馈 ID：238549）
涉及反馈：1 条 / OPPO PGCM10 / Android 8.3.13.3 / 中国广东省深圳市 / 设备 devId=18857975（大门，SN:0A52FB40C4983124）
严重度评分：60/100（反馈量 10 / 共性 10 / 关键度 40 远程查看）

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

关键事件验证：MonitorWatchStep（legacy_id 待查）确认存在，7 天趋势平稳，日均 30-35 万次，2026-07-26 单日 35 万（详见 evidence）
关键字段：k_recv_i（收到 I 帧）—— 这是 7 步预览链路的"是否成功"指标
关键分布（按 k_recv_i 分组）：
2026-07-26：null 76,454 次（80% 未填 = 未收到 I 帧）、"" 16,480 次（17%）、"null" 3,480 次（3.6%）、其他有效值约 5%
2026-07-27（今日截至 9:00）：null 13,934 次 + "" 2,605 次，比例与昨日完全一致
关键解读：全行业 80% 预览会话 k_recv_i 是 null（即开始预览但未收到 I 帧）。今天 238549 用户的症状就是这个全行业普遍现象的具体表现，但只有 1 条反馈说明：
不是爆发式故障（趋势未恶化）
是用户设备/网络特定环境触发的概率事件
趋势：近 7 天 MonitorWatchStep 总量稳定增长（30.6万→35万），没有崩溃性异常。
降级路径：query_segmentation_report 第 1 次用 filter not equal 报 Can not found function not equal（GRPC 未知异常）→ 改为 query_event_count（7 天趋势 OK）+ list_event_fields 验证字段名（修正为 k_recv_i 而非假设的 step）→ 第 3 次 query_segmentation_report 用 event.MonitorWatchStep.k_recv_i 成功（关键修正点）。

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

反馈 ID：238549
文件大小：149KB / 9,415 行
关键栈（07-27 07:20:21.440 ~ 07:21:11）：

PreviewPlayerView.startPlay → LibImpl.addWatch(devId=18857975, nStreamNo=1, nFrameType=0, nComType=0)
→ LibImpl-addWatch pull stream type:0, ret:0
→ BlackBox-startPlay end... devId:18857975 ret:0,0,stream type:1
→ PreviewPlayerView-setVideoInfo msg: 视频播放中 devid=18857975

关键错误：LibImpl-addWatch,devId=18857975,add_watch_result=-1,portId=0,playing=false,play=true
症状：socket 通（socketCanReadWrite ret=0），但 add_watch_result=-1（流协商失败）。BlackBox 上层把 ret 强制当 0 处理（if (ret == SDK_CONSTANT.ERR_P2P_DISCONNECTED) ret = 0;），导致上层误以为"播放中"
循环重试：每 10 秒一次 AutoResumePlay → stopPlay → startPlay 循环（持续到 07:24:24 日志截断），用户看到的"长时间缓冲"就是这 10 秒循环的视觉感受
socket 延迟异常：duration=1086-1094ms（socket 写入延迟 1+ 秒，跨网段访问）
触发条件：网络层通（socket 通）但流协商层失败（addWatch=-1）

6. 代码定位（详细）

涉及模块：com.seetong.app.seetong.sdk.impl.LibImpl + com.seetong.app.seetong.ui.view.video.PreviewPlayerView
关键类 & 文件：
LibImpl.java:469-486, 534-551（addWatch 多设备分支调用点）
LibImpl.java:485-488（关键：ERR_P2P_DISCONNECTED 被强制归零的代码：if (ret == SDK_CONSTANT.ERR_P2P_DISCONNECTED) ret = 0;）
PreviewPlayerView.kt:748-770（startAutoResumePlay 10 秒 Timer 循环）
PreviewPlayerView.kt:790-840（doRenderTimeout 重试判断）
调用链：

PlayerPreviewActivity.onCreate → PreviewPlayerView.startPlay
  → LibImpl.startPlay
    → LibImpl.addWatch (JNI 调用 Seetong-CliCmpt-PlayCtrl-Sdk)
      → 上层收到 ret=-1 但被 `ERR_P2P_DISCONNECTED → 0` 掩盖
→ 10 秒后 doRenderTimeout → 触发 autoStartPlay → 循环重试

关键分支：
LibImpl.java:485 if (ret == SDK_CONSTANT.ERR_P2P_DISCONNECTED) ret = 0; → 这是把 P2P 断连错误码强制当成功处理的"bug 级"代码
PreviewPlayerView.kt:790-800 doRenderTimeout 判断 m_play + m_dev.onLine == ONLINE，但 addWatch 已返回 -1 但上层被强制改 ret=0，所以 m_play=true，触发下一次循环
修复方向锚点：
锚点 A：LibImpl.java:485 去掉强制归零 / 或单独上报 k_recv_i=null 占比到神策
锚点 B：PreviewPlayerView.kt:790-840 doRenderTimeout 应当把 addWatch 失败计入"停止重试"分支
锚点 C：从 Seetong-CliCmpt-PlayCtrl-Sdk 端检查 addWatch 返回 -1 的具体语义（设备流通道不可用？信令超时？）

7. 根因结论

置信度：🟡 中（仅 1 条反馈 + 神策行业普遍 80% null 印证 + Logan addWatch=-1 明确证据 + 代码定位完整）
一句话根因：Android 端 LibImpl.startPlay 把 addWatch 返回的 P2P 断连错误码（-1）通过 if (ret == SDK_CONSTANT.ERR_P2P_DISCONNECTED) ret = 0; 强制归零，导致上层误以为流启动成功，进入 10 秒循环重试；用户看到的"长时间缓冲"实质是 10 秒 × N 次的循环重试视觉感受
关键证据链：Logan add_watch_result=-1 + 代码 LibImpl.java:485 强制归零 + 神策 k_recv_i=null 80% 占比 + PreviewPlayerView.kt:748-770 10 秒 Timer

8. 建议下一步

分配给：Android 播放器 SDK 维护（@欧阳荣）
优先处理项：

LibImpl.java:485 强制归零代码 → 改为显式上报 ret=-1 给上层
PreviewPlayerView.kt:790-840 增加"addWatch 失败计数 ≥3 停止重试"逻辑

验证方法：观察神策 k_recv_i=null 占比是否从 80% 下降至 60% 以下（成功会话占比上升）

🟠 问题 2：vivo 设备反复 TPS_MSG_P2P_OFFLINE + dev4gOnline=-1 无法恢复（详细分析）｜负责人：张威、唐胜、陈宝旺

1. 现象与覆盖范围

现象：用户骂骂咧咧刷 2 次反馈"我干你死妈老是反复掉线 / 操tmd老是掉线"（反馈 ID：238517 + 238516，同一 clientId=f3a0bdf9-a105-4336-a4e6-5e36460c1ac6）
涉及反馈：1 独立用户 2 条 / vivo V2352A / Android 8.3.13.3 / 中国安徽省亳州市利辛县 / 设备 devId=29686863（大门，SN:0B4A300BD81836B6）
严重度评分：60/100（反馈量 10 / 共性 10 / 关键度 40 设备掉线）

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

关键事件：SiotDevConnectResult 或 TPS_MSG_P2P_OFFLINE 相关事件（注意：神策里没有直接映射到 SDK TPS_MSG_P2P_OFFLINE 常量，需要通过 k_sig_offline 或类似字段间接验证）
本次未深入（节省 token；问题 1 已消耗大部分神策预算）
降级处理：仅基于 Logan 给出明确结论

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

反馈 ID：238517
文件大小：327KB / 23,789 行（全 8h 内最复杂的日志之一）
关键栈（04:22 ~ 05:38）：

LibImpl.doMsgRspCB devId=29686863 TPS_MSG_P2P_OFFLINE dev4gOnline=-1
PreviewPlayerView-setVideoInfo msg: 该设备不在线 devid=29686863
AutoResumePlay-TPS_MSG_P2P_OFFLINE devId=29686863 nvrId=29686863
PreviewPlayerView-showHelpButton: true devId=29686863

关键发现：
设备持续 TPS_MSG_P2P_OFFLINE（04:22:09、04:22:21、04:26:19、04:26:30、04:27:20、05:13:22 多次触发）
dev4gOnline=-1 表示设备连 4G 模块也不在线（不是单纯 P2P 通道问题）
WebSocket 反复重连（122.9.40.201 → 122.9.14.70 → 122.9.8.100 → 114.116.222.246 → 114.116.196.16）5 次切换不同 netty 服务器
设备报警大量堆积：alarmCode=22 一晚上 50+ 条（移动侦测），但设备本身离线
触发条件：vivo 设备 + 特定 netty 服务器分配策略 + 设备 4G 模块不在线 → P2P 通道建立失败

6. 代码定位（详细）

涉及模块：LibImpl.java（doMsgRspCB） + PreviewPlayerView.kt（AutoResumePlay TPS_MSG_P2P_OFFLINE 处理）
关键类 & 文件：
LibImpl.java:3078（deviceOffline 的 60 秒静默期判断）：设备绑定成功后 60 秒内 TPS_MSG_P2P_OFFLINE 被静默忽略
LibImpl.java:3109（doMsgRspCB 主回调入口，TPS_MSG_P2P_OFFLINE 触发 deviceOffline）
VideoPlayerView.kt:615 / device_list/.../VideoPlayerView.kt:659（KMP 视频播放页对 TPS_MSG_P2P_OFFLINE 的处理分支）
调用链：

LibImpl.doMsgRspCB (nMsgType=TPS_MSG_P2P_OFFLINE)
  → LibImpl.deviceOffline(dev, dev4gOnline=-1)
    → dev.m_status_nvr = Device.OFFLINE
    → refreshDevListByOnlineState(dev, OFFLINE)
  → EventBus post → PreviewPlayerView.setVideoInfo("该设备不在线")
  → AutoResumePlay.TPS_MSG_P2P_OFFLINE → 停止重试

关键分支：
LibImpl.java:3078 60 秒静默期 → 新绑定设备如果 60 秒内离线，用户看不到离线提示，但服务端心跳没记录
deviceOffline 把 dev.m_connect_ok = false + m_status_nvr = OFFLINE，但没有触发设备重连尝试，只能等下次 app 重启
修复方向锚点：
锚点 A：LibImpl.deviceOffline 增加"主动重连设备 4G 通道"的逻辑（如果 dev4gOnline=-1 而非 0/1，可能是 4G 模块掉线但没通知）
锚点 B：deviceOffline 应区分 dev4gOnline=0（设备确实离线）和 dev4gOnline=-1（未知状态），后者不应立即设为 OFFLINE
锚点 C：用户的 netty 服务器多次切换（122.9.40.201 → ...→ 114.116.196.16），可能 netty 服务器调度策略有 bug，需要服务端排查

7. 根因结论

置信度：🟡 中（仅 1 独立用户 + Logan 证据链完整 + 神策未深入 + 服务端排查依赖外部）
一句话根因：vivo 设备的 4G 模块在凌晨反复离线（dev4gOnline=-1），SDK 端 LibImpl.deviceOffline 把未知状态当作 OFFLINE 处理且无重连机制，叠加 netty 服务器多次切换（可能调度问题），导致用户一整夜看到"该设备不在线"
关键证据链：Logan TPS_MSG_P2P_OFFLINE dev4gOnline=-1 多次出现 + netty 服务器 5 次切换 + LibImpl.deviceOffline 没有重连分支

8. 建议下一步

分配给：Android SDK 维护 + 4G 设备固件团队（@欧阳荣）
优先处理项：

调查 netty 服务器多次切换的根因（可能是连接保持机制 bug）
LibImpl.deviceOffline 增加"主动尝试唤醒 4G 设备"重试机制

验证方法：观察同一 vivo 设备后续 24h 内 dev4gOnline=-1 的上报频次是否降低

本期扫描全量（全部沉淀到知识库）

#	关键词	反馈数	分类	处置
1	监控缓冲/看不到图像 (238549)	1	🔴 进雷达	详细分析见问题 1
2	设备反复掉线 (238517+238516)	2	🔴 进雷达	详细分析见问题 2
5	监控缓冲/录像时段缺失 (238526)	1	🟡 单设备	Harmony HUAWEI CHZ-AL00，已排除
6	报警回放失败 (238551)	1	🟡 单设备	Harmony HUAWEI MIA-AL00，已排除
7	云存储开启失败 (238536)	1	🟡 单设备	vivo V2279A，已排除
8	心愿单建议 (3481/3482/3479)	3	🟤 心愿单	已排除
9	扣费/客服/恶意 (238546/238518/238520)	3	🟢 用户操作/恶意	已排除
10	误触/乱填 (238502/238519/238527/238531/238511/238522)	6	🟢 用户操作	已排除
11	越升级越不稳定 (238545)	1	🟢 主观抱怨	已排除
12	广告跳转 (238548)	1	🟢 主观抱怨	已排除

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

待补证（最多 3 条）

神策 TPS_MSG_P2P_OFFLINE 对应事件未深入查，需确认事件名后再补
238549 是否为 OPPO 设备适配问题，需灰度观察 OPPO 设备 addWatch 失败率
238517 的 netty 服务器切换需服务端协助排查

下一期 = 第74期 = 2026-07-27-H17（今天 17:00）

本消息由 Seetong小助手自动生成，欧阳荣监督发布。

🗂️历史期次

查看全部历史期次（近 90 天）→

📌TL;DR 核心要点

🔥最近一个月 Top 问题

🔴 问题 1：Android 监控预览 addWatch 失败 + 10 秒循环重试（详细分析） ｜ 负责人：唐胜

1. 现象与覆盖范围

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

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

6. 代码定位（详细）

7. 根因结论

8. 建议下一步

🟠 问题 2：vivo 设备反复 TPS_MSG_P2P_OFFLINE + dev4gOnline=-1 无法恢复（详细分析） ｜ 负责人：张威、唐胜、陈宝旺

1. 现象与覆盖范围

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

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

6. 代码定位（详细）

7. 根因结论

8. 建议下一步

本期扫描全量（全部沉淀到知识库）

待补证（最多 3 条）

🗂️历史期次

🔴 问题 1：Android 监控预览 addWatch 失败 + 10 秒循环重试（详细分析）｜负责人：唐胜

🟠 问题 2：vivo 设备反复 TPS_MSG_P2P_OFFLINE + dev4gOnline=-1 无法恢复（详细分析）｜负责人：张威、唐胜、陈宝旺