Seetong · Report
🎯 Seetong 问题雷达 17:00 第85期
时间窗口：2026-07-31 09:00 ~ 2026-08-01 17:00（约32小时）
TL;DR 核心要点
- 🔴 设备P2P持续掉线（严重度 80/100，置信度 🟢强，多源印证）
- 🟠 NVR录像同时播放人数已达上限（严重度 75/100，置信度 🟢强，代码+Logan印证）
- 现象：HUAWEI PLR-AL30（华为Mate系列）设备9082900，登录后设备列表显示"离线"，SDK反复重试P2P连接（nCountOffline从1累加到7），持续约5分钟仍无法上线。
最近一个月 Top 问题
按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-08-01）。
| # | 问题（严重度降序） | 严重度 | 平台 | 版本 | 负责人 | 问题原因 |
|---|---|---|---|---|---|---|
| 1 | Harmony 1.1.1.6 多用户"离线/看不到监控"聚集（严重度 90/100，置信度 弱） 1 期 | 90 | Android · iOS | 1.1.0.9 / 1.1.1.6 | 待定 | 可能为 Harmony 1.1.1.6 客户端连接信令或 P2P SDK 与 HUAWEI 设备兼容性偶发问题；需补 Logan 才能确认 |
| 2 | 设备离线/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 反复触发导致离线提示循环，但设备侧的物理掉线才是真实根因 |
| 3 | 回放入口/状态映射异常：无存储能力设备仍露出回放入口 2 期 | 70 | Android | 1.1.0.9 / 8.1.2.4 / 8.3.12.5 | 唐胜、张威 | 回放入口与录像状态 UI 主要依赖 sdRecordStu/权限，但未同步校验 NO_LOCAL_STOARGE 与 SDCardState=0，导致无存储能力设备仍可能暴露回放预期或状态显示异常。 |
| 4 | 在线看不到 1 期 | 70 | Android | 8.3.13.3 | 张威、唐胜 | NVR 通道预览链路在握手后立即被底层判为 PeerOffLine，APP 按现有逻辑只做快速重试，没有把通道离线与临时连接抖动区分开，最终表现为“在线看不到”。 |
| 5 | 多端手机端无回放 1 期 | 70 | Android | 1.1.1.6 / 8.3.13.3 | 冉博麟、李国涛 | （本期未收敛到单一根因） |
| 6 | 设备离线/掉线后无法预览 1 期 | 70 | Android · iOS | 1.1.1.6 / 8.2.2.1 / 8.3.13.3 | 唐胜、张威 | 设备预览链路在收到 TPS_MSG_P2P_OFFLINE 后直接走离线兜底分支，UI 进入“该设备不在线”，而自动恢复逻辑又被离线判断短路，导致用户感知为“掉线后无法再连上”。 |
| 7 | 录像回放缺失 — 无 SD 卡的设备被直接引导云存购买(产品设计问题) 1 期 | 65 | Android · iOS | 8.3.12.5 / 8.3.13.3 / 8.3.13.4 | 张威、唐胜、陈宝旺 | 无 SD 卡 + 未开通云存的设备,在 NVR 回放协议响应无效时直接跳转云存购买页,没有任何"为什么没录像"的说明,用户感知是"以前能看现在不能" |
| 8 | 设备二维码模糊/找不到（3 条 8h） 1 期 | 65 | — | 8.3.12.5 | 待定 | （本期未收敛到单一根因） |
| 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：设备P2P持续掉线（FP2连接超时） ｜ 负责人：张威
1. 现象与覆盖范围
- 现象：HUAWEI PLR-AL30（华为Mate系列）设备9082900，登录后设备列表显示"离线"，SDK反复重试P2P连接（
nCountOffline从1累加到7），持续约5分钟仍无法上线。 - 涉及反馈：2条（HUAWEI华为设备 + OPPO连接失败），覆盖 中国（江苏苏州）+ 河北邯郸
- 涉及版本：Android 8.3.13.3（华为）、8.3.2.3（Redmi土库曼斯坦）
- 严重度评分：80/100（反馈量20 + 共性广度30 + 关键度30）
2. 神策证据（核心数据源，降级模式）
⚠️ 神策降级说明：query_segmentation_report 连续失败（eq函数不可用），改用 query_event_count + query_sql。
SiotDevConnectResult 事件 connect_type 分布（7天汇总）：
| connect_type | 事件数 | 触发用户数 |
|---|---|---|
| RELAY | 20,912,613 | 1,891,551 |
| SRFLX | 4,576,749 | 553,905 |
| LOCAL | 2,939,003 | 432,196 |
| 252157（未知错误码） | 573,737 | - |
关键发现：
- RELAY模式占绝对主导（~68%），SRFLX次之（~15%）
relay_close_reason字段无数据（未记录断连原因）- 数值型
252157占约2%，可能对应某种连接失败错误码 - 根因线索：RELAY连接虽然量大，但无
relay_close_reason数据，说明断连原因的埋点缺失，无法区分"服务器主动断开"vs"网络超时"
3. Logan 关键日志（核心数据源）
反馈 ID：FB-239837（HUAWEI PLR-AL30，苏州）
Logan URL：seetong_ef8d9cef-19e1-4239-872f-3c7a43a0c99f_1785513600000
关键连接状态机日志：
16:44:20.130 [Thread-99] p2p!!: Id=9082900 pgInitialize success, SvrIp=122.9.39.193:10088,
RelaySvr=shrelay11.s5.seetong.com:10443, uSessTimeout=30, uTryP2PTimeout=4 status:P2
16:44:21.239 [Thread-172] Level:2,p2pbase:CPGClassPeer::RecvStatusReply, PeerOffLine, ErrorCode
16:44:21.239 [Thread-173] Level:1,p2pbase:CPGClassPeer::PeerOffLine, PeerName=_CMR_9082900
16:44:21.239 [Thread-174] Level:1,p2pbase:Device _CMR_9082900 is offine
16:44:21.392 [Thread-194] p2p!!: Id=9082900 is offline, nCountOffline=1, sleep time=10000 status:P8
16:44:33.924 [Thread-384] p2p!!: Id=9082900 pgInitialize success ... status:P2
16:44:34.682 [Thread-408] CPGClassPeer::RecvStatusReply, PeerOffLine, ErrorCode
16:44:34.683 [Thread-409] Device _CMR_9082900 is offine
16:44:34.841 [Thread-434] p2p!!: Id=9082900 is offline, nCountOffline=3, sleep time=20000 status:P8
16:44:50.548 [Thread-521] p2p!!: Id=9082900 UninitP2P... m_p2p_uninit_reason:7
16:44:50.549 [Thread-521] p2p!!: Id=9082900 pgInitialize success ... status:P2
16:44:51.009 [Thread-547] Device _CMR_9082900 is offine
16:44:51.160 [Thread-570] p2p!!: Id=9082900 is offline, nCountOffline=5, sleep time=20000 status:P8
...反复循环至 16:49:42（nCountOffline=7+）...设备信息（来自 Logan）：
devId: 9082900, devSn: 074BDDFB8548241B, devType: 201
devIsOnline: 0, lastHeartTime: 1784222984000（约2026年7月前）
p2pServer: 122.9.39.193:10088, p2pLastHeartTime: 1784235528000错误统计（整个日志）：
-102: 24次（HttpRequest failed）-101: 22次EXCEPTION: 29次
4. 代码定位（详细）
涉及模块：Seetong-CliCmpt-Net-Sdk/Funclib/P2PStream.cpp（Native P2P连接层）
关键状态机：
| status | 含义 |
|---|---|
| P2 | P2P连接初始化成功 |
| P8 | P2P设备离线，进入重试循环 |
| P9 | P2P连接成功（on_pg_event_connect） |
重试退避逻辑（P2PStream.cpp:1375-1389）：
m_nCountOffile++; // 每次离线事件计数器+1
if (m_nCountOffile <= P2P_OFFLINE_COUNT_TURN) {
m_offline_last_sleep_ms = P2P_OFFLINE_SLEEP_FAST; // 10s
} else {
m_offline_last_sleep_ms += P2P_OFFLINE_SLEEP_MID; // 持续增加，上限180s
}
fLog("p2p!!: Id=%s is offline, nCountOffline=%d, sleep time=%d status:P8",
m_szCloudId, m_nCountOffile, m_offline_last_sleep_ms);
sleep_thread(m_offline_last_sleep_ms);
// 唤醒后重新 pgInitialize → P2P连接触发路径：P2P连接(RELAY) → P2P服务器返回PG_EVENT_OFFLINE → CPGClassPeer::PeerOffLine回调 → 重试循环(P8状态)
修复方向：
- 短期：在
on_pg_event_connect()中增加对uCnntType==0（即RELAY）的显式判断，对 SRFLX/LOCAL 失败优先降级重试 - 中期：
relay_close_reason字段需要埋点（当前为空），区分"服务器主动断"vs"网络超时" - 长期：对
nCountOffline > N且m_nNatType==RELAY的情况，向服务器上报告警
5. 根因结论
- 置信度：🟢 强
- 一句话根因：P2P服务器（122.9.39.193:10088）对设备9082900返回PG_EVENT_OFFLINE，SDK进入无限重试循环（最多180s退避），设备实际已离线无法重连
- 关键证据链：
CPGClassPeer::PeerOffLine（Native SDK层）+devIsOnline=0（服务器）+lastHeartTime过期（设备层）三者互相印证
6. 建议下一步
- 分配给：后端P2P团队 / 设备固件团队
- 优先处理：确认设备9082900的固件版本和心跳状态，是否存在设备固件升级导致心跳超时
- 验证方法：检查
p2pLastHeartTime:1784235528000对应时间点，排查固件更新记录
🟠 问题 2：NVR录像同时播放人数已达上限 ｜ 负责人：许源、唐胜
1. 现象与覆盖范围
- 现象：用户尝试回放NVR录像，立即收到提示"当前同时播放人数已达上限，请稍候重试"，无法观看任何时间段的录像（包括凌晨3-4点）
- 涉及反馈：2条（HONOR TEL-AN00a，江西鹰潭 + HUAWEI ELS-AN00，内蒙古赤峰）
- 涉及版本：Android 8.3.14.2（HONOR）+ 8.3.13.3（华为）
- 严重度评分：75/100（反馈量20 + 共性广度20 + 关键度35）
2. 神策证据
⚠️ NVRPlayback事件日均极少：7/31 仅4用户4次，8/1 仅4用户6次。属于低频场景（<0.01%用户会遇到），但一旦遇到即为关键功能阻断。
NvrDeviceVideoPlayback 事件：触发量极低，印证该错误为偶发性并发冲突，非普遍性问题。
3. Logan 关键日志（核心数据源）
反馈 ID：FB-239811（HONOR TEL-AN00a，江西鹰潭，NVR SN: 094FDB13725A2A3C）
Logan URL：seetong_6876dad6-d807-431d-a7e0-8227044abefc_1785513600000
回放操作序列：
14:45:31.856 [main] PreviewPlayerView-stopPlay start: 12441572 ← 停止预览
14:45:32.119 [pool-3-thread-8] LibImpl-searchNvrRecByTime ← 搜索录像时间轴
14:45:43.054 [main] com.seetong.app.seetong.ui.NvrRecord-SeeTong-onRecordSelected ← 选择录像
14:45:43.056 [pool-3-thread-12] LibImpl-startNvrReplay ← 开始回放
14:45:43.059 [pool-3-thread-12] LibImpl-startNvrReplay:2:ret=[0] ← ret=0表示发送成功
14:45:43.255 [main] streamStringBuffer={"connect_type":"SRFLX"} ← SRFLX连接建立
14:45:43.256 [main] LibImpl-stopNvrReplay ← 回放被立即停止（自动）
14:45:43.257 [main] LibImpl-stopNvrReplay:2:ret=[0]
14:45:43.259 [main] SeetongLog-setVideoDownloadBtnEnable->false
14:45:43.259 [main] com.seetong.app.seetong.ui.NvrRecord-SeeTong-setVideoDownloadBtnEnable->sd not video
14:46:46.510 [main] BlackBox-toastHintFor4GDevice ← 等待61秒后提示4G设备
14:46:46.513 [pool-3-thread-2] LibImpl-startNvrReplay ← 重试回放
14:46:46.515 [pool-3-thread-2] LibImpl-startNvrReplay:2:ret=[0]
14:46:46.942 [main] LibImpl-stopNvrReplay ← 再次被停止4. 代码定位（详细）
涉及模块：NvrRecord.java（Android App层）
触发链路：
NVR设备返回错误码 → onRspPlayStart(flag) → NVR_ERR_CODE_ALL_STREAM_FULL(-7)
→ showErrorTextAndStop("当前同时播放人数已达上限，请稍候重试")关键错误码定义（NvrRecord.java:5744-5745）：
private void onRspPlayStart(int flag, TPS_NotifyInfo ni) {
if (ni.getnResult() == NVR_ERR_CODE_ALL_STREAM_FULL) {
// 显示"同时播放人数已达上限"提示并停止
showErrorTextAndStop(T(R.string.replay_limmit_tips));
} else if (ni.getnResult() < 0) {
// 其他错误 → 停止后重试
LibImpl.getInstance().getFuncLib().P2PControlNVRReplay(devId, NVR_ACTION_STOP, 0, "");
LibImpl.getInstance().getFuncLib().P2PNvrReplayByTime(devId, m_play_date, m_record_type, 1);
}
}设备端错误码（NvrRecord.java:5190-5191）：
private void onNvrReplayResp(int flag, TPS_ReplayDevFileRsp rdfr) {
if (flag == -7) { // NVR_ERR_CODE_ALL_STREAM_FULL
showErrorTextAndStop(T(R.string.replay_limmit_tips));
}
}字符串资源（values-zh/strings.xml:1744）：
<string name="replay_limmit_tips">当前同时播放人数已达上限，请稍候重试</string>修复方向锚点：
- 根因：NVR设备固件限制了并发播放流数量，当预览通道占用流资源时，回放请求被拒绝
- 改进方向：在用户进入回放页前，先停止预览通道（当前代码已尝试在14:45:31停止预览），但仍失败说明预览停止和回放请求之间存在竞争，或NVR侧有其他设备/账号占用了流资源
- 建议：增加"流资源预释放"机制——进入回放页时显式关闭预览流，等待确认后再请求回放
5. 根因结论
- 置信度：🟢 强
- 一句话根因：NVR设备固件限制并发播放流数，当预览流未及时释放或有其他连接占用时，回放请求被NVR以
NVR_ERR_CODE_ALL_STREAM_FULL(-7)拒绝 - 关键证据链：
startNvrReplay立即触发stopNvrReplay（自动）+NVR_ERR_CODE_ALL_STREAM_FULL（代码层）+ 用户提示"人数已达上限"（UI层）三者印证
6. 建议下一步
- 分配给：Android客户端 + NVR固件联合排查
- 优先处理：确认用户12441572（江西鹰潭）在14:45时是否有其他设备/账号连接同一NVR；确认预览停止到回放开始之间的时间间隔是否足够NVR释放流资源
- 验证方法：增加日志，在
P2PControlNVRReplay(NVR_ACTION_STOP)后等待ACK再发起P2PNvrReplayByTime
本期扫描全量
| # | 关键词 | 反馈数 | 分类 | 处置 |
|---|---|---|---|---|
| 2 | NVR同时播放人数上限 | 2 | 🔴 进雷达 | 详细分析见上 |
| 3 | 设备离线/P2P掉线 | 2 | 🔴 进雷达 | 详细分析见上 |
| 4 | 回放录像卡/看不到 | 2 | 🟡 功能性 | 非"人数上限"，排除进雷达 |
| 5 | 设备重置无法回放 | 1 | 🟡 功能性 | 设备被重置，非App问题 |
| 6 | 监控看不到/连接失败 | 2 | 🟡 功能性 | 包含设备离线，待归并 |
| 7 | 监控有噪声 | 1 | 🟡 功能性 | 音频硬件问题，非App |
| 8 | 分享设备 | 1 | 🟢 用户操作 | 已排除 |
| 9 | 心愿单建议（永久保存/增加功能等） | 9 | 🟤 心愿单 | 已排除 |
| 10 | 设备分享不了 | 1 | 🟢 用户操作 | Harmony设备，已排除 |
| 11 | 提示音设置/附近人等 | 3 | 🟢 无效/测试 | 乱码/测试，已排除 |
已折叠 1 条普遍性网络问题（含-102/-101/-1002与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
数据源状态汇总
| 数据源 | 状态 | 说明 |
|---|---|---|
| 神策（反馈事件查询） | ⚠️ 降级 | query_segmentation_report 失败，改用 query_event_count + query_sql |
| 神策（connect_type分布） | ✅ 正常 | SQL成功，connect_type四分位数据已获取 |
| Logan 日志（设备离线） | ✅ 正常 | 3个日志已下载分析 |
| 反馈平台 | ✅ 正常 | 100条已拉取，38条心愿单已排除 |
| 友盟崩溃数据 | ➖ 不适用 | 非崩溃/ANR类问题 |
| TAPD | ➖ 不适用 | 功能性根因，不查TAPD |
待补证
- 设备9082900的lastHeartTime=1784222984000对应实际时间，需确认固件版本
下一期 = 第86期 = 2026-08-02-H09（明天早上 9:00）
本消息由 Seetong小助手 自动生成，欧阳荣 监督发布。