🎯 Seetong 问题雷达 17:00 第232期

🔴 问题 1：Android 8.4.1.6 KMP 回放「播放失败」误报——首帧已到却被判失败（HONOR DNN-AN00） ｜ 负责人：唐胜、陈宝旺

1. 现象与覆盖范围

• 现象描述：用户从设备预览页点进回放，页面已开始出画，但界面弹出「播放失败」提示，随后画面恢复正常。用户主观感受即反馈原话「打不开画面」。
• 涉及反馈：257211（1 条直接证据）/ 设备 HONOR DNN-AN00 / 版本 8.4.1.6 / 网络 4G（socketCanReadWrite ipv4 正常）/ 地区 内蒙古赤峰
• 关联同族：257141（H17 前一期 H09 窗口「回放不可以看了」，Android 8.4.1.6）与本期 257211 同属 KMP 回放失败提示族，但上一期 Logan 显示用户未真正进入回放页，故本期不合并、不重复计算。
• 严重度评分：63 / 100（反馈量 10 / 共性 20 / 关键度 33）
• 反馈量 10：窗口内 1 条直接命中（跨 8h 仅 1 次投诉，非爆发式）
• 共性 20：涉及 1 个机型 × 1 个版本 × 1 个地区（2 维）
• 关键度 33：录像回放（30）叠加「已出画仍提示失败」造成用户感知层面的假故障，向上浮动 3 分

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

• 本期未取得：本窗口时间预算优先用于 Logan 逐帧取证（该问题的唯一硬证据来源），神策 NvrMonitorFrameResult / MonitorWatchStep 事件与失败码分布未查询，按 skill 规则降级，不做重复重试。
• 既有口径参考（来自第 231 期与本 skill 记录）：NvrMonitorFrameResult 为性能事件（字段为 recv_frame_time / awaken_ms / lag_rate），不含 result / error_code，因此「回放失败码分布」无法由该事件承载，需以客户端 Logan 为准。
• 待补证：下一期需先用 list_event_schemas 确认是否存在承载回放启停结果的事件，再补 7 天趋势；本期不臆测事件名。

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

• 反馈 ID：257211（日志 577,839 字节 / 30,037 行，覆盖 12:19:16 ~ 12:24:39）
• 关键时间线（同一设备 devId=32296536、同一播放窗口 viewId=29、同一 renderer 263200147）：

• 判读：

1. 底流是通的——onNvrReplayResp ret=0 带回完整视频参数（H265 / 2304×1296 / 15fps / 2000kbps），首帧 1.36 秒到位，时间轴随后正常走秒。
2. 失败事件是假的——两次 play failed event 的 result=0 均为「成功」语义，且全部落在首帧之前（-1.256s / -1.009s）。
3. 用户没有真正拿到可用画面——从第一次失败事件到 mark card playback first frame 之间存在约 1.3 秒的失败提示窗口，这正是用户提交「打不开画面」的触发点。

• 上下文与输入参数：recordType=268435455（0x0FFFFFFF，即全类型位掩码）、date=20261014121906、targetTimeSec=44346（12:19:06）。
• 引文（关键 4 行）：

[L2495] 12:22:37.716 RecordPlayerView-startReplay: devId=32296536, date=20261014121906, recordType=268435455 oldViewId=-1 oldOwner=null renderer=263200147
[L2499] 12:22:37.821 PlayBackPage: receive playback play failed event, devId=32296536, result=0, currentDevId=32296536, ballDevId=
[L2505] 12:22:38.068 PlayBackPage: receive playback play failed event, devId=32296536, result=0, currentDevId=32296536, ballDevId=
[L2507] 12:22:39.077 RecordPlayerView-onRecvFirstFrame: devId=32296536 this=22299266 viewId=29 owner=263200147 renderer=263200147 isOwner=true

6. 代码定位（详细）

• 涉及模块：Seetong5.0ForSeetong/Seetong5.0/kmp/（Android KMP 共享层，回放页走 Kuikly 渲染）
• 关键类与方法：
• RecordPlayerView.startReplay() — kmp/src/main/java/com/seetong/kuikly/export/RecordPlayerView.kt:220-264
• RecordPlayerCallback.onReplayError(device, errorCode) — 同文件 :975
• 调用链：

PlayBackPage(卡片事件点击, targetTimeSec=44346)
  → RecordPlayerView.startReplay(timestamp, recordType)            :220
      → device.m_view_id = playbackWindowId                        :238   ← 先置 29
      → recordPlayCallback?.onStartReplay(device)                  :249   ← 先回调
      → ioExecutor { startNvrReplay(...) }                         :252
            → 失败重试 1 次                                         :253
            → post { device.m_view_id = -1; device.m_video = null
                     recordPlayCallback?.onReplayError(...) }      :256-258  ← 失败分支回退
  → RecordPlayerView.onRecvFirstFrame(dev)                         :940   ← 1.36s 后才到

• 关键分支：startReplay 把 m_view_id 置为 29（:238）早于 IO 线程上的 startNvrReplay（:252）返回；只要返回码非 0 就会把 m_view_id 回退为 -1（:256）并回调 onReplayError（:258）。此时底层取流可能已经在进行中，于是形成「上层已判失败、底层却在出画」的分裂状态。
• 修复方向锚点（按优先级）：

1. RecordPlayerView.kt:249 / :252 — onStartReplay 回调与 m_view_id 置位应晚于 startNvrReplay 的返回码判定，或引入「待确认」中间态，避免失败提示抢在首帧之前。
2. RecordPlayerView.kt:256-258 — 失败分支不应无条件把 m_view_id 回退 -1；应判定「同一 viewId 是否已有取流活动」，有则只记录而不回退。
3. RecordPlayerView.kt:930-943 — onRecvFirstFrame 应能清除/撤销此前已弹出的失败提示（幂等收敛），保证「出画即无失败态」。
4. PlayBackPage（Kuikly 侧，receive playback play failed event 的消费方）— 失败提示应加去抖窗口：事件到达后若在 N 秒内收到首帧则不再展示。

• Git 归属：git blame 显示 :250-259 失败分支为 sheng.tang（原提交 e368654a43 2026-04-17，ed2785b29c 2026-08-03 加入重试），主责归属 唐胜。

7. 根因结论

• 置信度：🟡 中
• 一句话根因：KMP 回放页在 startNvrReplay 返回码判定完成之前就先发出了「播放失败」事件（两次，result=0），而底层取流实际成功、首帧 1.36 秒后到达，形成「先报失败、后出画」的假故障。
• 关键证据链：Logan 单条内自证（startReplay → 两次 play failed → onNvrReplayResp ret=0 → onRecvFirstFrame → 时间轴走秒），不依赖神策与友盟。因非崩溃类问题，未查友盟；因根因属客户端播放链路，未查 TAPD。

8. 建议下一步

• 分配给：唐胜（KMP 回放链路）
• 优先处理项：

1. 复现「失败事件早于首帧」的时序竞态，确认 startNvrReplay 返回码与 onRecvFirstFrame 的真实先后关系。
2. 失败提示增加去抖与撤销逻辑，保证出画后不再残留失败态。

• 验证方法：在 HONOR DNN-AN00 或同型 8.4.1.6 机型上，从预览页进入回放（fromPreviewPlayback=true）连续 20 次，断言「失败提示出现次数 = 0」或「失败提示出现后 2 秒内必被首帧撤销」；同时校验 viewId 在整段回放中不再出现 29 → -1 的异常回退。

🟠 问题 2：HarmonyOS 1.1.1.11 回放功能聚集性失效——无声、无法查看、卡顿三类并存 ｜ 负责人：唐胜

1. 现象与覆盖范围

• 现象描述：HarmonyOS 用户在同一 8 小时窗口内集中反映回放类问题，且形态不一致：
• 回放无声有图：「回放只能听到声音看不到图像，直播可以」（257174）
• 回放无法查看：「自设备启用一直是无法查看卡回放，一直显示让格式化内存父」（257178）、「回放不了」（257209）
• 回放卡顿：「看回放卡顿，根本看不了」（257198）
• 设备侧失败：「设备登陆不了」（257224）、「打不开」（257223）、「老是离线怎么回事」（257216）、「半夜突然离线一直显示离线，别的监控正常，未动过线路」（257177）
• 涉及反馈：12 条（HarmonyOS 本窗口全部反馈）/ 版本 1.1.1.11 单一版本 / 机型 10 个（HUAWEI SGU-AL10、CHZ-AL00、BRA-AL00、TYR-AL00、BLK-AL80 ×2、ADY-AL10、ALT-AL10 ×2、ALN-AL00、MLN-AL00、ALN-AL10）/ 地区覆盖 浙江、山东、内蒙古、辽宁、河南、广东、湖南、江苏等 8 个以上省级行政区
• 严重度评分：62 / 100（反馈量 20 / 共性 30 / 关键度 30）
• 反馈量 20：窗口内 12 条，其中回放类 4 条（落在 3-5 条区间）
• 共性 30：涉及 10 个机型 × 8 个以上地区 × 2 类设备形态（IPC / NVR）（≥3 维）
• 关键度 30：录像回放（30），未向上浮动（证据仅文案层，不叠加）

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

• 本期未取得：HarmonyOS 侧无任何可关联的客户端 Logan（0/12），神策 Harmony 事件亦未在本窗口查询。本问题的证据仅停留在反馈文案聚类层，属 skill 规则下的弱证据场景。
• 口径说明（必须显式披露）：本窗口 Harmony 反馈数 12 条，占全窗口 13.6%，但样本量与机型分布不足以支撑「版本级回归」判断——12 条来自 10 个不同机型，平摊到单机型不足 2 条，无法区分「版本缺陷」与「设备端个体故障 / 存储卡老化 / 网络抖动」。
• 待补证：需神策 Harmony 端 NvrMonitorFrameResult 等价事件与 7 天趋势；本期不做事件名臆测。

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

• Logan 未提供：12 条 Harmony 反馈的 loganFileDownloadUrl 全部为空字符串（对照同窗口 Android 76 条中 62 条提供链接，覆盖率 81.6%；iOS 本窗口 0 条反馈）。
• 缺口量化（连续 11 期阻塞，最高优先）：

• 结论：本问题无法给出类名:行号级证据，根因置信度受此硬性制约，只能给出中置信度的方向性判断。

6. 代码定位（详细）

• 涉及模块：HarmonyOS 端回放链路（Seetong-App-Harmony 不在本机标准路径，本期未能定位到具体文件与行号）
• 可用锚点（跨端共享语义）：
• 回放会话与 SD 卡信息：PlaybackVM.fetchEventList / PlayBackPage.requestPlaybackSdInfo（Android KMP 同名实现见 RecordPlayerView.kt 同族调用，Harmony 应存在对应实现）
• 存储格式化提示：PlayBackPage.updateCardSdFormatThumbTip（257178 的「让格式化内存卡」提示应与该逻辑同源）
• 提示：257178 的「一直显示让格式化内存卡」若与 Android 侧 updateCardSdFormatThumbTip 同源，则其判定条件（sdSupportThumb / unsupported / dismissedUntil）值得优先比对——本窗口 Android 侧该提示在 257211 与 257162 两个样本中均为 show=false，未误弹。
• 修复方向锚点（方向性，非行号）：

1. Harmony 回放页需补齐与 Android 对等的 SD 卡异常判定与提示去抖。
2. Harmony 端必须补齐 Logan 上报（见下条），否则该类问题将持续无法定位。

7. 根因结论

• 置信度：🔴 弱（受 Logan 全窗口缺失制约）
• 一句话根因：无法确定单一根因——12 条 Harmony 反馈横跨 10 个机型，回放类 4 条在「无声 / 无法查看 / 卡顿」三种形态间分散，尚不足以认定为 1.1.1.11 的版本级回归；当前最可靠的结论是「Harmony 端回放相关功能存在多点故障信号，但缺乏可定位证据」。
• 关键证据链：仅反馈文案聚类 + 跨平台 Logan 覆盖率对比；无神策、无 Logan、无友盟（非崩溃类）、无 TAPD。
• 必须写明的不确定性：不能排除设备端存储卡个体故障、NVR 通道配置差异、弱网等非客户端因素。

8. 建议下一步

• 分配给：HarmonyOS 团队（回放链路）+ 客户端基础组件（Logan 上报）
• 优先处理项：

1. 补齐 HarmonyOS Logan 上报链路——这是连续 11 期最高优先级的阻塞项，不补齐则本类问题永远不会收敛。
2. 回访回放类 4 位用户（257174 / 257178 / 257198 / 257209），按「设备型号 + 设备形态（IPC/NVR）+ 存储卡状态 + 网络类型」采集问卷，把 12 条反馈收窄到可归因的少数场景。

• 验证方法：修复 Logan 上报后，确认真机可产出 loganFileDownloadUrl 非空；再以 3 天为观察窗，比对 Harmony 回放类反馈量与 Logan 证据可用率的反向关系（证据可用率上升 → 应能给出具体类名行号）。

本期排除项与扫描全量（全部沉淀到知识库）

Markdown 里保留全部反馈；HTML 呈现时渲染器会自动折叠 🟣 普遍性网络问题，只展示更有价值的条目，无需在本段手工删减。

排除项分布

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

网络类版本分布（68 条）

68 条来自 55 个独立客户端，单客户端最多 11 条（vivo V2464A，辽宁营口，8.3.14.2）——属同一用户连续重试，非跨用户普遍爆发。

全部非网络类反馈（20 条）

单独说明：257162（Android 8.4.1.6，「硬盘不能储存影像，回放没有录像可看，软件升级不了」）

• Logan 已取得（110,609 字节 / 5,609 行，覆盖 07:01:44 ~ 09:14:20），关键事实：
• PlaybackVM.fetchEventList: 设备服务返回 count=0（20261014 与 20261013 两天均为 0 段录像）
• RecordPlayerView-bindDevice state: devId=16283809-CH-2 replaying=false viewId=-1（全程未进入过回放）
• 设备能力串含 NO_LOCAL_STOARGE 标志 → 该设备本无本地存储能力，与用户「硬盘不能储存影像」的表述一致
• 判读：属设备侧存储配置/形态问题（NO_LOCAL_STOARGE），非 App 客户端缺陷。用户三条诉求（硬盘、回放、升级）中前两条根因同为「设备无本地存储」。
• 处置：不进雷达；建议转 seetong-feedback-triage 由客服确认设备型号与是否插卡。若后续多期再现同一 NO_LOCAL_STOARGE 机型，再考虑升级为产品文案问题（用户预期管理）。

数据源状态汇总

待补证

• 问题 1 的神策侧：需 list_event_schemas 确认承载「回放启停结果」的事件名（NvrMonitorFrameResult 为性能事件，不含失败码），再补 7 天趋势；连续 4 期未完成。
• 问题 1 的复现面：本窗口仅 1 条直接反馈，需确认「失败事件早于首帧」是否为 8.4.1.6 新引入；建议在 H09 第 231 期已建任务 T-20261014-090647-bbbe 下追加本窗口证据。
• 问题 2 的 Logan 缺口（连续 11 期，最高优先）：Harmony 端 0/12 提供链接。建议固定披露该比值以量化缺口，并优先回访回放类 4 位用户。
• 问题 2 的归因：12 条 Harmony 反馈横跨 10 个机型，样本不足以判定版本回归；需按「设备形态 + 存储卡状态 + 网络类型」采集后收窄。
• 257177 / 257216（Harmony 离线）：与第 231 期 257110（天津，SGT-AL50，「断电也不管事了」）形态相近，均属「已联网却显示离线 / 断电不恢复」族；因本窗口 Harmony 无 Logan，本期不合并进问题 2 的根因结论，仅作同族线索记录。
• 257223 / 257224（Harmony「打不开」「设备登陆不了」）：文案过短、无 Logan，无法区分是设备侧、账号侧还是客户端；待 Logan 上报补齐后重判。
• 257208（广告 + 售后投诉）：非技术类，建议转客服；其中「怎么开始有广告了」与第 218 期已判定「商业化策略非缺陷」的结论一致，不重复分析。

任务账本

说明一：问题 1（失败事件竞态）与 T-20261013-090000-a1b2（首帧迟至 105 秒）同属 Android 播放链路但根因不同（失败事件误报 vs 取流空转），按 skill 规则独立建单，未合并。

说明二：问题 2 未新建任务，因其作为「HarmonyOS 1.1.1.11 回放大范围不可用」的新形态，并入 T-20260926-170258-2226 同族跟踪，避免同一根因域重复建单。

说明三：T-20260926-170258-576a（回放熄屏）本窗口虽无熄屏类反馈，但新增了反向证据——257211 的 30,037 行 Logan 中 Screen awake requested 零命中（KuiklyRenderActivity.kt:88 的 PlaybackScreenAwake 标签），说明该窗口内回放页仍未调用 setKeepScreenOn 桥接（KMPBridgeModule.kt:107），与第 218 期结论一致，属未修复状态，故追加证据而非结案。

下一期 = 第233期 = 2026-10-15-H09（明天早上 9:00；窗口 今日 17:00 ~ 明日 09:00）