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

🟠 问题 1：Android 8.4.1.6 在线状态不一致导致卡录像无法打开 ｜ 负责人：张威

现象与覆盖范围

• 反馈 259131：2026-10-23 18:39，Android 8.4.1.6，HONOR ALI-AN00，山东德州。反馈原文为“老爱掉线，录像视频没法看”。
• Logan 显示，用户在 18:37:46 从报警列表进入回放。当时沿用的最近一次设备列表缓存仍标记设备在线，但缓存内最后心跳只有当天上午的记录。云存接口明确返回 30600201 服务未开通，随后用户切到卡回放；卡回放页面已加载，但在反馈前没有成功出帧。
• 18:38:20 至 18:39:21 的 61 秒内，同一个设备连续上报 7 次 TPS_MSG_P2P_OFFLINE，间隔约 5～12 秒。该窗口内未检索到 TPS_MSG_RSP_NVR_REPLAY 或 onReceiverMediaFirstFrame，说明客户端没有拿到可确认的回放首帧。
• 严重度评分：80 / 100。反馈量 10（1 条直接反馈，但有完整故障窗口日志）、共性广度 30（Android、版本、机型、地区四个维度）、业务关键度 40（录像取证与远程查看被阻断）。
• 去重判定：与任务 T-20261016-170803-b4da“Android 单设备随机离线”同域。本期新增了“本地缓存在线字段与心跳年龄冲突，且卡回放无首帧”的完整证据，应更新既有任务，不重复创单。

神策证据

• 当前 16 小时窗口内，Android 8.4.1.6 的 DeviceVideoPlayback 共 6,397,312 PV / 2,498,047 UV，其中失败 277,657 PV，明确失败率 4.332%。
• 失败码前三为 SA106006 86,308 PV / 47,056 UV、SA106007 77,108 PV / 62,687 UV、SA106001 65,915 PV / 55,294 UV。按现有枚举，三者分别为设备时间轴为空、设备离线和录像获取超时。
• 10 月 17 日至 23 日的同一版本自然日失败率为 4.125%、4.103%、4.011%、4.013%、4.061%、4.086%、4.046%；10 月 24 日 0 时至 09:06 的未完整日失败率为 4.978%。当前样本尚不能证明全天恶化，但反馈发生时设备离线码有持续量级。
• 当前窗口 SiotDevConnectResult 有 1,206,836 PV。该事件没有可用的 result 字段；p2p_hold_success=0 主要落在 RELAY 连接，不能直接当作 P2P 失败率，也不能代替逐设备状态判断。
• 反馈 clientId 未映射到神策 distinct_id，因此上述是版本级背景证据，不能把 259131 精确计入失败事件。

Logan 关键日志

• 反馈 ID：259131。日志 9736 行，覆盖 2026-10-23 11:37 至 18:39。
• L519：11:37:46，最近一次设备列表响应返回 devIsOnline=1、lastHeartTime=1792722483000、p2pLastHeartTime=1792723174000。换算后分别为 10:28:03 和 10:39:34；到 18:39 反馈时，这份缓存记录已陈旧约 8 小时。
• L519 之后：回放页进入云存，两个请求均返回 30600201 服务未开通。该结果解释了云存回放入口，但对卡回放的 P2P 离线没有解释力。
• L9388 与 L9390：18:37:51 再次确认云存服务未开通，同时卡回放页完成加载。
• L9479、L9493、L9683、L9731、L9732、L9733、L9734：18:38:20 至 18:39:21 连续出现 TPS_MSG_P2P_OFFLINE dev4gOnline=0。
• L9736：18:39:22 用户提交反馈，故障窗口结束。日志中没有可证明卡回放已经出帧的对应事件。

代码定位

• 涉及模块：Seetong-CliCmpt-Net-Sdk/Funclib/Model/SiotDevSession、Seetong-App-Android 的 LibImpl 与设备列表状态同步。
• SiotDevSession.cpp:696-717：OnDevOffline 先把会话状态写成离线，再通过 CallBackOffline 发出 TPS_MSG_P2P_OFFLINE 或 NVR 离线事件；这里没有附带心跳年龄供业务层判断状态是否仍可信。
• LibImpl.java:3092-3128：deviceOffline 收到离线事件后直接把 m_connect_ok=false、m_status_nvr=OFFLINE，并刷新设备列表；没有校验服务端 devIsOnline 的新鲜度、P2P 重试结果或短暂抖动窗口。
• LibImpl.java:3283-3313：TPS_MSG_P2P_OFFLINE 分支读取 dev4gOnline 后调用 deviceOffline，因此 dev4gOnline=0 会立即覆盖本地在线状态。
• MainActivity2.java:1843-1855 与 DeviceFragment.java:1092-1099：离线事件继续广播到设备列表和当前业务页，回放页没有独立的“传输连接异常但设备在线待确认”状态。
• 修复方向锚点：在 deviceOffline 前引入 lastHeartTime/p2pLastHeartTime 新鲜度门禁和连续失败确认；将“云端设备在线”“P2P 可连接”“当前播放会话可出帧”拆成三个状态，禁止单次 P2P 事件直接覆盖云端在线事实。

根因结论

• 置信度：现象 🟢 强；客户端连续 P2P 离线 🟢 强；本地缓存在线记录陈旧 🟢 强；设备本身是否真实离线或仅 P2P 不可达 🟡 中。
• 一句话根因：客户端继续使用一份已陈旧约 8 小时的在线缓存，同时又允许单次 P2P 离线事件直接覆盖设备状态；状态模型没有区分云端心跳、P2P 连通和播放出帧，导致用户看到“在线但录像打不开”，且回放页缺少可恢复路径。
• 关键证据链：反馈原话“掉线、录像没法看” → 最近一次设备列表缓存在线字段为 1，但心跳约 8 小时未更新 → 卡回放进入后 61 秒内连续 7 次 P2P 离线 → 反馈前没有 NVR 回放响应或首帧。
• 明确不下的结论：当前日志不能区分设备主控断网、4G 模组异常、P2P 节点不可达和在线缓存未及时刷新。不能把所有失败码 SA106007 都归为同一个客户端缺陷。

建议下一步

• 分配给：张威牵头核对 Net SDK 的离线判定和心跳时效；Android 设备列表负责人复核状态覆盖逻辑，回放负责人补齐首帧失败恢复。
• 用设备 SN 0BAEED98A2C238DA 回查 2026-10-23 18:30～18:40 的服务端在线快照、网关心跳、P2P 会话和 4G 模组状态，确认约 8 小时心跳为何仍被标记在线。
• 状态层增加心跳年龄门禁：缓存或接口数据超过阈值时显示“在线状态待确认”，不得继续以新鲜在线设备展示；P2P 离线至少经过多次确认后再切换离线态，并允许自动重连。
• 回放页分别提示“云端在线但 P2P 连接失败”“设备离线”“无录像”“云存未开通”，并提供重试、重新唤醒、切换回放类型的最小恢复操作。
• 埋点补充 devId + rid + devIsOnline + lastHeartAgeMs + p2pLastHeartAgeMs + p2p_retry_count + playback_stage + first_frame_result，让后续可从同一设备串联服务端状态与首帧结果。
• 回归覆盖“在线但 P2P 不可达”“P2P 抖动后恢复”“服务端在线但心跳过期”“无云存但卡回放正常”四类场景，每类连续进入和切通道 20 次。

🟠 问题 2：Android NVR 通道切换丢失当前回放时间位置 ｜ 负责人：唐胜

现象与覆盖范围

• 反馈 259159：2026-10-23 21:09，Android 8.4.1.6，Redmi M2012K11AC，辽宁大连。用户说明同一段 2026-10-20 17:50 录像此前可在通道一与通道二之间直接切换，现在通道一看不到后切到通道二，必须重新调整时间才能播放。
• 用户描述的是跨通道时间轴连续性退化，不是单个录像文件缺失。问题每次切换都需要重复操作，属于核心回放工作流中的明确体验回退。
• 严重度评分：70 / 100。反馈量 10（1 条明确反馈）、共性广度 30（Android、版本、机型、地区四个维度）、业务关键度 30（录像回放）。
• 去重判定：与任务 T-20260922-170415-9496“Android 卡回放时间跳转异常”同域，但触发动作从拖动时间轴扩展为通道切换。本期更新既有任务，不重复创单。

神策证据

• Android 8.4.1.6 当前窗口 DeviceVideoPlayback 为 6,397,312 PV / 2,498,047 UV，明确失败 277,657 PV，失败率 4.332%。
• 该事件能说明回放大盘仍有持续失败，但不能定位到反馈设备的通道切换动作，也不能说明切换前后的时间游标是否连续。
• 当前窗口查询 NvrDeviceVideoPlayback 未返回可用行，因此没有按通道拆分的服务端证据。该空缺不代表没有发生问题，只表示当前埋点无法量化通道切换。

Logan 与附件

• 反馈 259159 未提供 Logan，无法直接读取切换前后的 m_replay_timestamp、mCurrentPlayTime、新设备录像索引结果及是否发生 seekNvrReplay。
• 因此本期能确认用户报告的时间连续性退化，并结合代码定位到高风险路径，但不能确认真实设备上具体丢失在哪一次状态赋值。

代码定位

• 涉及模块：Seetong-App-Android/Seetong5.0/Seetong5.0/app/src/main/java/com/seetong/app/seetong/ui/NvrRecord.java。
• NvrRecord.java:7396-7433：openSelectedChannel 读取新通道后调用 stopReplay(true)，替换 m_device 与 m_device_id，随后直接调用 loadData(true)；切换前没有保存 m_time_line.getSliderTimestamp() 或当前可见播放时间。
• NvrRecord.java:2624-2661：loadData 先清空 m_records，再 refreshScaledTimestamp(m_find_date.getTime()) 并把 mCurrentPlayTime 重置为 m_find_date.getTime()。这里保存的是查找日期基准，不是用户正在观看的精确时间游标。
• NvrRecord.java:5563-5597：新通道录像返回后继续使用独立的 m_replay_timestamp 决定显示位置；若该值为 0，则回退到当前日期的“当前时间减 1 小时”或首段录像。通道切换时两个时间源没有被统一快照和恢复。
• NvrRecord.java:6084-6135：正常的同设备 seek 使用 replaySeek 并保留精确时间，但通道切换绕过了该路径，说明问题集中在“换设备后的数据重载”，不是通用时间轴拖动控件。
• 修复方向锚点：在 openSelectedChannel 前保存 {oldDevId, sliderTimestamp, playbackState}；新通道录像索引返回后先校验时间是否落在可用录像段，再调用统一 seek 恢复原位置；无录像时明确提示并定位到最近片段。

根因结论

• 置信度：现象 🟡 中；代码风险路径 🟡 中；单一根因 🔴 弱。
• 一句话根因：通道切换会销毁旧通道录像上下文并重载新通道，但代码没有显式保存和恢复当前时间轴游标，导致精确时间在 m_find_date、mCurrentPlayTime 与 m_replay_timestamp 之间发生回退或分叉。
• 关键证据链：用户给出“此前可直接切、现在必须重选时间”的明确回归对照 → 切换通道调用 loadData(true) → 重载过程清空记录并重置当前时间 → 正常 seek 路径未被复用。
• 明确不下的结论：缺少 Logan，无法排除新通道在该时刻确实无录像、设备返回索引延迟或旧请求晚到覆盖新通道。根因需要用真机日志确认后再升级为强置信度。

建议下一步

• 分配给：唐胜复核 Android 回放数据重载，许源复核通道切换 UI 与状态保存；由提交者补充一次真机复现日志。
• 通道切换前快照当前设备、精确时间、播放/暂停状态和当前录像类型；新通道索引完成后恢复同一时间，若命中录像间隙则定位最近可播片段并提示原因。
• 为切换请求增加设备 ID 与请求代次校验，保证旧通道迟到的录像索引/出帧事件不能覆盖新通道会话。
• 回归用例覆盖：通道一无录像切通道二、通道二无录像、来回快速切换、播放中切换、暂停中切换、跨录像间隙切换、横竖屏切换，各连续执行 20 次并核对时间误差不超过 1 秒。

本期扫描全量

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

反馈接口返回 total=97 / fetched=97 / complete=true / pages=2。上表按主问题唯一归类，合计 97 条。259199 的 AI 误报已有长期任务 T-20261018-090818-00a1，本期不重复深挖；其 Logan 仅证明客户端开启了人形能力与灯控能力，未包含设备端算法判定帧，不能据此认定模型误报原因。

心愿单亮点

• 5471：希望 App 远程开关监控设备，具备明确运维价值，但需要先区分设备能力、权限与误操作保护。
• 5472：希望在现有对讲外增加通话功能，价值中等，需评估与设备音频能力和现有语音链路的复用程度。
• 5478：用户强烈反感 App 内广告过多，属于长期产品体验信号，建议按场景统计曝光频次和关闭率后再调整策略。

数据源状态

• 反馈平台：✅ 正常。首次登录遇到“验证码不正确”，按技能要求在相同窗口重试成功；最终 total=97 / fetched=97 / complete=true / pages=2，逐条分类覆盖全部 97 条。
• 心愿单：✅ 正常。total=15 / fetched=15 / complete=true / pages=1。
• Sensors：✅ DeviceVideoPlayback 当前窗口、失败码和八日趋势查询成功；SiotDevConnectResult 当前窗口确实存在，但该事件没有 result 字段，p2p_hold_success=0 不可单独解释为 P2P 失败；NvrDeviceVideoPlayback 当前窗口无可用行，已明确标注为通道维度观测缺口。
• Logan：⚠️ 部分可用。259131 的 9,736 行日志覆盖故障前后，直接证明陈旧心跳、连续 P2P 离线和无首帧；259159 未提供 Logan。
• 友盟：⏭️ 未调用。本期两项核心问题均为功能性连接与回放问题，不是崩溃或 ANR。
• TAPD：⏭️ 未调用。当前没有新的 BUG 单号，已有统一任务账本承载。
• 代码仓：✅ Seetong-App-Android 与 Seetong-CliCmpt-Net-Sdk 已只读定位；Android 当前分支工作区无未提交业务改动，本期未修改代码。
• 任务账本：问题 1 沿用 T-20261016-170803-b4da；问题 2 沿用 T-20260922-170415-9496，两项均保持 P1 / captured。
• 待补证：需服务端按设备 SN 回查 2026-10-23 18:30～18:40 的在线状态与心跳过期策略；需回访 259159 并补采切换通道前后的 Logan，确认时间游标丢失点。

下一期 = 第252期 = 2026-10-24-H17.md（今天下午 17:00；窗口 今日 09:06:54～17:00）