Seetong · Report
🎯 Seetong 问题雷达 17:00 第244期
时间窗口：2026-10-20 09:00:32～17:06:35（Asia/Shanghai）
TL;DR 核心要点
- 🔴 Android 8.4.1.6 在 HONOR 平板访问 TS8108D35、固件 4.6.1.8 的 NVR 卡回放时，KMP 回放会话在线取流已返回成功，却连续 10 秒收不到首帧并自动重试。反馈 258544 的 Logan 中，16:45、16:46、16:50 至少三次出现 startNvrReplay ret=0 后 card playback frame timeout, frameGapMs≈10000；同一设备同一通道在此前 1.71 秒完成原生预览首帧，说明设备在线且取流链路可用，故障已收敛到 KMP 回放渲染器或首帧事件路由，严重度 60 / 100，现象置信度强、根因置信度中。
- 🟠 本期没有第二个达到 60 分门槛的新问题。Android 进程重启、HarmonyOS 回放与监控异常、HarmonyOS 旧画面问题均在 24 小时内存在同域任务或现成证据链，本期按去重规则不重复展开。
- 258544：Android 8.4.1.6、HONOR ROL-W60、河北唐山，10-20 17:01:03 反馈：NVR TS8108D35 升级到 4.6.1.8 后，用平板经常不能回放，有时能看也会跳秒 3～4 秒；实时预览正常，手机端使用较少但“好像也没事”。
最近一个月 Top 问题
按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-20）。
| # | 问题（严重度降序） | 严重度 | 平台 | 版本 | 负责人 | 问题原因 |
|---|---|---|---|---|---|---|
| 1 | Android 8.4.1.6 及 HarmonyOS 1.1.1.11 单设备随机离线、P2P 恢复失败 18 期 · 157 条反馈 | 100 | Android · HarmonyOS | 1.1.1.11 / 8.4.1.6 / 1.1.1 | 陈宝旺、冉博麟、唐胜、李国涛 | 257582、257639 已确认是服务端心跳长期停更并伴随 P2P 离线，App 只是按离线状态展示；问题更可能在设备端、设备网关／P2P 服务或固件恢复机制，而不是 Android 播放器单点故障。 |
| 2 | Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达 1 期 · 3 条反馈 | 90 | Android · iOS | 8.4.1.6 | 陈宝旺、许源 | 现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。 |
| 3 | HarmonyOS 画中画状态导致切换设备后仍显示前一路画面 1 期 · 3 条反馈 | 90 | HarmonyOS | 1.1.1.11 / 1.1.2.3 | 张跃译 | 多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。 |
| 4 | 升级后回放体验整体退化 4 期 · 18 条反馈 | 85 | Android · iOS | 8.4.1.6 / 8.3.14.2 | 唐胜、许源、欧阳荣、谭伟 | 8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。 |
| 5 | KMP 回放页未申请屏幕常亮，回放中手机自动息屏 11 期 · 29 条反馈 | 84 | Android · HarmonyOS | 8.4.1.6 / 8.4.1 / 8.4.2 | 唐胜、陈宝旺、许源、谭伟 | KMP 回放页的屏幕常亮能力已在代码中完整实现（KMP 公共层 → 桥接层 → Android 宿主层齐备），但承载该实现的提交只落在 feature_v8.4.2 一条分支上，feature_v8.4.4、master、hotfix_v1.1.1 全部不含，因此所有已发布版本（Android 8.4.1.6 / HarmonyOS 1.1.1.11）在运行时都走不到 FLAG_KEEP_SCREEN_ON，回放过程中发生系统级息屏。 |
| 6 | SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断 3 期 · 9 条反馈 | 80 | Android · HarmonyOS · iOS | 8.4.1.6 / 1.1.1.11 | 唐胜、张威、陈宝旺 | 设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。 |
| 7 | iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算 2 期 · 8 条反馈 | 80 | Android · iOS | 8.4.1.6 / 8.3.11.3 / 8.4.106 | 陈宝旺、欧阳荣、谭伟 | iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。 |
| 8 | iOS 8.1.2.4 微信登录授权码重复提交触发 30100225 1 期 · 3 条反馈 | 80 | iOS | 8.1.2.4 / 8.1.204 / 8.4.106 | 待定 | 微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。 |
| 9 | iOS 老版本微信登录空授权码触发 30100222 1 期 · 1 条反馈 | 80 | iOS | 8.1.3.5 / 8.1.305 / 8.1.503 | 位冬 | 微信授权回跳在当前旧版 iOS 上返回了空 code，客户端没有把它视为失败边界，仍向服务端提交空授权码，最终稳定触发 30100222。 |
| 10 | iOS 8.4.1.6 冷启动点击离线报警推送后未进入回放 1 期 · 2 条反馈 | 70 | iOS | 8.4.1.6 / 8.4.106 | 欧阳荣、谭伟、陈宝旺 | 当前冷启动没有留下通知响应回调或 KMP 回放路由证据，用户实际停留在普通启动链路；最可能的缺口是冷启动通知回调 / 参数分支未被当前处理逻辑承接或没有兜底，但尚不能确认是 APNs payload 缺 content、回调未到、视图条件拦截还是路由失败。 |
🔴 问题 1：Android 平板 KMP NVR 卡回放持续无首帧并反复重试 ｜ 负责人：唐胜、张威
现象与覆盖范围
- 258544：Android
8.4.1.6、HONORROL-W60、河北唐山，10-20 17:01:03 反馈：NVRTS8108D35升级到4.6.1.8后，用平板经常不能回放，有时能看也会跳秒 3～4 秒；实时预览正常，手机端使用较少但“好像也没事”。 - 用户同时提供了 NVR 型号、固件版本、访问终端差异和异常表现，属于可直接复现的结构化反馈，不是“网络不好”一类泛化描述。
- 严重度评分：60 / 100。反馈量 10（1 名独立用户）；共性广度 20（覆盖 NVR
TS8108D35与4.6.1.8，并形成“平板异常、手机相对正常”的访问终端对照）；业务关键度 30（录像回放属于事后取证与历史核查主链路）。 - 去重判定：账本中没有同条件的平板 KMP NVR 卡回放无帧任务；新建
T-20261020-170615-54cd，状态P1 / captured。
神策证据
NvrDeviceVideoPlayback在 10-13～10-20 的逐日触发为：10-133 次 / 3 人、10-166 次 / 2 人、10-181 次 / 1 人、10-20 截至本次查询4 次 / 2 人；其余日期无事件。- 10-20 的 4 条事件均为
RELAY。其中唯一一条dev_identify=TS8108D35-4.6.1.8-202609101915样本的首帧字段为736 ms，但该事件的客户端标识与反馈 258544 无法关联，不能据此判定本用户已经出帧。 - 该事件提供
first_frame_time、first_frame_time_ms、duration、connect_type、nvr_version等性能字段，没有result/error_code；且全天仅 4 次，不能把事件量当作 NVR 回放总量或失败率。 - 因此神策只能确认：同固件版本存在少量成功首帧事件，NVR 回放并非全量中断；不能覆盖本用户的平板 KMP 会话，也无法给出失败率。核心证据以 Logan 为准。
Logan 关键日志
- 反馈 258544 的 Logan 共 27,472 行、617,453 字节，覆盖当天的 NVR 预览与回放操作。设备列表中 NVR
43700083为在线状态，通道43700083-CH-2在故障前可正常预览。 16:45:48.468～16:45:50.474，原生预览PlayerPreviewActivity与PreviewPlayerView对43700083-CH-2连续收到首帧，证明设备在线、鉴权、P2P／RELAY 取流和视频解码主链可用。16:45:52.634，KMP 页面记录KMPPlayBackVideoView.playVideoByTime, devId=43700083-CH-2；16:45:52.639记录startNvrReplay ret=0。16:46:02.634，KMP 记录card playback frame timeout, frameGapMs=10001，随后停止当前回放并立即重试；第二次startNvrReplay仍为ret=0。16:46:11.640再次启动，16:46:21.648再次记录card playback frame timeout, frameGapMs=10007。16:50:40.325，同一 NVR 通道在原生预览中再次收到首帧；16:50:42.034切到 KMP 卡回放并启动，16:50:52.031第三次记录card playback frame timeout, frameGapMs=10004。- 三次 KMP 尝试均在请求返回成功后等待满约 10 秒，日志中没有对应的
KMPPlayBackVideoView.onRecvFirstFrame，也没有可刷新卡回放帧监听的MSG_REPLAY_SET_POSITION业务时间戳。 - 期间虽反复出现
receive playback play failed event, result=0，但 KMP 代码只在result < 0或达到并发上限时处理该事件；本次实际触发重试的是 10 秒无帧监听，不能把result=0误写成播放失败根因。
代码定位
- 涉及模块：
seetong-kmp/modulePlayback、Seetong-App-Android/.../kmp。 KMPPlayBackVideoView.kt:223-245：KMP 调用playVideoByTime()后进入RecordPlayerView.startReplay()；首帧与业务帧分别通过kmp_device_record_first_frame_event、kmp_device_record_frame_event回传。RecordPlayerView.kt:234-264：开始回放前把device.m_video指向当前openglesRender、设置m_view_id=29，再异步调用startNvrReplay()；本地方法先返回 0，真实取流请求结果仅用于非零重试。RecordPlayerView.kt:930-951：只有收到MSG_RECEIVER_MEDIA_FIRST_FRAME才进入onRecvFirstFrame()；只有收到MSG_REPLAY_SET_POSITION才把业务帧时间回传给 KMP。CardPlayBackPageLogic.kt:2672-2724：启动 10 秒无帧监听；超时后先stopDev()，再重置画面变换并重新执行playOrSeek()，形成“启动成功 → 无首帧 → 停止 → 重放”的闭环重试。- 调用链：KMP
playVideoByTime→RecordPlayerView.startReplay→LibImpl.startNvrReplay返回 0 → SDK 首帧／业务帧消息 →RecordPlayerView.onSdkMessage→ KMP 事件 → 卡回放首帧消费与无帧监听刷新。 - 当前断点在“SDK 请求已接受”之后、“KMP 首帧／业务帧事件到达”之前。现阶段最可疑的是 KMP 渲染器与
PlayerDevice.m_video的绑定时序、页面生命周期切换，或窗口 ID 对应的首帧消息没有路由到当前 KMP View；尚无证据认定 NVR 固件或公网链路异常。
根因结论
- 置信度：现象 🟢 强；根因 🟡 中。
- 一句话根因：同一在线 NVR 通道能被原生预览正常解码，但切入 KMP 卡回放后当前会话持续收不到首帧或业务帧；KMP 播放器绑定／首帧事件路由存在缺陷，导致每 10 秒停止并重试。
- 关键证据链：用户明确“平板卡回放异常、预览正常、手机相对正常” → 日志中同一通道原生预览收到首帧 → KMP 三次
startNvrReplay ret=0后均连续 10 秒无帧 → 代码的无帧监听按设计停止并重放，完全对应用户看到“经常不能回放或跳秒”。 - 明确不下的结论：不把
result=0当作失败原因，不判定为 NVR4.6.1.8固件全量故障，也不把该问题与 HarmonyOS 回放不可用或 Android 16 分屏进程重启合并。
建议下一步
- 分配给：KMP 回放架构负责人陈宝旺为主，Android 回放桥接负责人唐胜配合；任务
T-20261020-170615-54cd，状态P1 / captured。 - 在 HONOR
ROL-W60、Android8.4.1.6、在线 TS8108D354.6.1.8上复现，连续执行进入 KMP 卡回放、切换 CH-1／CH-2、暂停恢复、seek 和前后台切换，每轮至少 10 次。 - 为每次播放增加
requestId，同时记录 KMP View 实例、openglesRender、Surface、device.m_video、m_view_id、startNvrReplay返回码、onNvrReplayResp、MSG_RECEIVER_MEDIA_FIRST_FRAME、MSG_REPLAY_SET_POSITION、首帧耗时和当前页面生命周期。 - 修复方向：在启动取流前确保当前 KMP View 的渲染器已经完成绑定；首帧、业务帧和失败事件都携带
requestId，丢弃旧会话回调；无帧重试达到上限后展示明确错误或回退原生播放器，禁止持续静默重放。 - 回归矩阵覆盖平板与手机、H.265 与 H.264、原生预览与 KMP 卡回放、前后台切换、通道切换、暂停恢复和连续 seek；验收标准为在线通道 3 秒内出首帧、10 次连续切换无超时。
本期扫描全量
| 分类与处置 | 反馈数 | 反馈 ID |
|---|---|---|
| 🔴 NVR 卡回放无首帧，进入问题 1 | 1 | 258544 |
| 🟡 Android／iOS 进程重启单点，与近期进程重启任务同域观察 | 2 | 258538、258473 |
| 🟡 HarmonyOS 回放、录像或监控异常，24 小时内同域重复 | 5 | 258523、258512、258511、258477、258521 |
| 🟡 HarmonyOS 点击不同设备仍显示首个画面，24 小时内同域重复 | 2 | 258474、258461 |
| 🟡 设备离线、无连接或售后支持单点 | 7 | 258537、258535、258525、258503、258480、258465、258464 |
| 🟡 其他回放、录像或报警媒体单点 | 4 | 258489、258488、258483、258460 |
| 🟡 OSD 修改或同步失败，同一用户连续提交 | 2 | 258528、258527 |
| 🟡 设备删除、恢复出厂或重新绑定咨询 | 7 | 258526、258522、258504、258495、258494、258493、258492 |
| 🟡 夜视能力单点，需设备侧能力位补证 | 1 | 258463 |
| 🟤 广告展示诉求，转产品频控评估 | 1 | 258536 |
| 🟢 内容过短、语义不明或未形成缺陷证据 | 3 | 258513、258482、258459 |
已折叠 1 条普遍性网络问题（含-102/-101/-1002与中/英/俄/法/西/葡/土/阿/日多语言网络提示模板，如Проверьте телефонную сеть、Please check your mobile network）；全量明细见同名 Markdown 知识库。
反馈接口按 2026-10-20 查询返回 total=86 / fetched=86 / complete=true，再按 09:00:32～17:06:35 精确纳入；上表按主问题唯一归类，合计 86 条。258544 发生于 17:01:03，位于本次实际扫描终点之前。258474 与 258461、258495～258492 的连续提交分别按用户级问题聚类，不按提交次数放大严重度。
心愿单、数据源与待补证
心愿单亮点
| 心愿单 ID | 平台 / 版本 | 诉求 | 价值判断 |
|---|---|---|---|
| 5409 | Android / 8.4.1.6 | 有线网络恢复后设备应自动重连，不应要求断电重启 | ⭐⭐⭐ 直接关系离线恢复与售后成本 |
| 5407 | Android / 8.4.1.6 | 去除容易误点的收费小广告 | ⭐⭐⭐ 与同窗口 258536 反馈互相印证，需产品评估频控与关闭按钮生命周期 |
| 5406 | Android / 8.4.1.6 | 希望能查看过去一年至更长的低成本云录像 | ⭐⭐ 涉及云存储成本、套餐与长期留存 |
| 5401 | Android / 8.4.1.6 | 建议研发带屏幕、可调灯光的工程宝 | ⭐⭐ 属于安装调试工具形态的新设备机会 |
数据源状态
- 反馈平台：✅ 正常。
total=86 / fetched=86 / complete=true，窗口内 86 条全部纳入扫描。 - 心愿单：✅ 正常。
total=10 / fetched=10 / complete=true。 - 神策：✅ 可查询。
NvrDeviceVideoPlayback趋势与字段检查成功；事件不含结果／错误码且本日仅 4 条，只用于说明 NVR 回放性能样本和埋点边界，不计算全局失败率。 - Logan：✅ 核心证据完整。258544 Logan 覆盖 27,472 行，能够直接比较原生预览首帧与 KMP 回放无帧超时。
- 代码仓：✅ 正常。已定位
KMPPlayBackVideoView、RecordPlayerView和CardPlayBackPageLogic的启动、首帧事件与无帧重试链路。 - 友盟：⏭️ 本期主问题为功能链路无首帧，不是崩溃或 ANR 趋势分析，不将崩溃率混作回放失败率。
- TAPD：⏭️ 未调用。当前已有可复现的产品、固件和端侧日志，先用任务账本推进客户端修复，避免历史 Bug 干扰根因。
待补证
- 258544 的 NVR 设备侧日志、固件
4.6.1.8的升级前后对照，以及平板与手机使用相同录像时间点时的 P2P 建流、H.265 解码和首帧时间线。 - KMP View 的实际
Surface尺寸、openglesRender绑定时刻、PlayerDevice.m_view_id变化，以及首帧消息是否到达但被旧 View／旧窗口消费。 - Android 258538 的完整进程重启日志仍缺异常栈；iOS 258473 的“app 重启”缺少可读堆栈，两者继续沿用近期任务观察，不并入本期 NVR 结论。
NvrDeviceVideoPlayback仅有 4 条/日且无失败状态，建议补充requestId、result、error_code、入口类型、首帧耗时和重试次数，否则线上无法量化 KMP 无帧率。
下一期 = 第245期 = 2026-10-21-H09.md（明天上午 09:00；窗口 今日 17:06:35～明日 09:00）