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

🔴 问题 1：HarmonyOS 1.1.1.11 回放不可用，失败原因仍不可区分 ｜ 负责人：陈宝旺、李国涛

现象与覆盖范围

• 258402：HarmonyOS 1.1.1.11、HUAWEI BRA-AL00、湖南湘西，10-19 21:52 反馈“没有回放”。
• 258430：HarmonyOS 1.1.1.11、HUAWEI HBP-AL00、山东泰安，10-20 01:27 反馈“没法看回放”。
• 258436、258437：同一用户、HarmonyOS 1.1.1.11、HUAWEI JUY-AL50、河南信阳，05:44 与 05:45 连续反馈“怎么没有回放”，按一名独立用户计。
• 合计 4 条反馈、3 名独立用户、3 款机型、3 个省级地区；均发生在 3 小时 25 分钟内，且均为 HarmonyOS 1.1.1.11。
• 严重度评分：80 / 100。反馈量 20（3～5 条档，按独立用户计）；共性广度 30（跨 3 款机型、3 个地区）；业务关键度 30（回放属于录像取证与事后核查主链路）。
• 去重判定：与既往 HarmonyOS 回放不可用问题同域，沿用任务 T-20260926-170258-2226，不重复创建一个“没有回放”的同义任务；本期新增 1 小时内 3 名独立用户证据，因此仍进入雷达。

神策证据

• HarmonyOS 应用壳 1.1.1.11 在 DeviceVideoPlayback 中没有 seetong_app_version 值；按既有版本映射检查内部版本 8.4.1.6，10-13～10-20 的每日样本为：
• 10-13：总 8,362、成功 7,962、失败 400，失败率 4.78%。
• 10-14：总 7,786、成功 7,402、失败 384，失败率 4.93%。
• 10-15：总 7,182、成功 6,882、失败 300，失败率 4.18%。
• 10-16：总 6,991、成功 6,589、失败 402，失败率 5.75%。
• 10-17：总 7,632、成功 7,267、失败 365，失败率 4.78%。
• 10-18：总 6,615、成功 6,235、失败 380，失败率 5.74%。
• 10-19：总 5,398、成功 5,126、失败 272，失败率 5.04%。
• 10-20 截至当前快照：总 932、成功 858、失败 74，失败率 7.94%；该日是未完整自然日，不能外推全天。
• 10-19 的明确失败码为：SA106001 获取录像超时 92 次／84 人，SA106007 设备离线 48 次／34 人，SA106005 获取设备录像时间轴失败 47 次／31 人，SA106012 存储卡未初始化 40 次／12 人，SA106006 设备录像时间轴为空 22 次／11 人，另有 SA106008 无存储卡 11 次／9 人、SA106010 存储卡不可读写 5 次／2 人、SA106013 存储卡初始化中 5 次／3 人。
• 这些失败码说明该版本回放故障并非单一分支，但没有反馈 ID 或用户 ID 级关联，不能把本窗口 4 条反馈分别指派给某个失败码。
• 对照 MonitorFrameResult，HarmonyOS 内部版本 8.4.1.6 在 10-19 为成功 6,668,720 次、失败 158,113 次，失败率约 2.32%，说明实时出图主链路没有整端中断；该事件不能代表录像时间轴、存储卡或回放引擎。
• 证据边界：1.1.1.11 的版本字段没有进入部分事件，无法计算该应用壳版本的独立点击级失败率；8.4.1.6 只能作为内部构建代理口径，不能写成 HarmonyOS 全平台故障率。

Logan 关键日志

• 258402、258430、258436、258437 的 loganFileDownloadUrl 均为空，4 条均无端侧日志。
• 因此本期无法取得 TPS_MSG_P2P_CONNECT_OK、TPS_MSG_P2P_OFFLINE、ts_AddWatchEx 返回值、录像时间轴响应、SD 卡状态或首帧回调，也不能把“没有回放”直接归因为设备离线、录像为空或播放器错误。
• 用户均未提供录像类型、设备 SN、云回放或卡回放入口、具体错误提示；问题现象成立，链路断点仍未确定。

代码定位

• 涉及模块：seetong-app-harmony/feater/playDevice/src/main/ets/view/replay/ReplayPage.ets、seetong-app-harmony/feater/playDevice/src/main/ets/service/DeviceServiceImpl.ets、seetong-app-harmony/feater/playDevice/src/main/ets/view/kuikly/KMPCloudPlaybackVideoView.ets。
• ReplayPage.ets:153-155：声明 isOffline 并明确注明“目前未赋值”。
• ReplayPage.ets:3875-3898：卡回放提示区只有在 isOffline=true 时显示设备离线提示；当前状态没有稳定赋值路径，用户可能只看到空白或通用空态。
• DeviceServiceImpl.ets:5533-5548：普通回放入口调用 TSNapi.ts_AddWatchEx() 后，仅以 ret == 0 判断开流请求是否被接受；异步响应中的业务错误码没有继续传给页面。
• KMPCloudPlaybackVideoView.ets:73-79：播放器 onError 只发送固定字符串 video onError，原始媒体错误、HTTP 状态和播放器错误码均被丢弃。
• 调用链：点击回放 → 原生/KMP 回放页 → 获取云录像时间轴或卡录像列表 → ts_AddWatchEx() → 播放器 Video 组件 → 首帧或 onError。当前代码只能说明错误透传和离线态赋值不足，不能证明在 3 名用户处由同一客户端分支触发。

根因结论

• 置信度：🔴 弱。
• 一句话根因：可确认 HarmonyOS 1.1.1.11 在短时间内出现跨机型、跨地区的回放不可用簇；神策显示超时、离线、时间轴失败和存储卡异常并存，端侧日志缺失，当前无法收敛到单一根因。
• 关键证据链：3 名独立用户集中在约 3.5 小时内报告“没有回放／没法看回放” → 对应构建近 7 天持续存在约 4%～6% 的明确回放失败 → 10-19 失败码同时包含超时、离线、时间轴失败和存储异常 → 代码确认 AddWatchEx 与播放器错误没有稳定透传到页面。
• 明确不下的结论：不判定为 HarmonyOS App 全局崩溃，不把所有“没有回放”解释成设备离线，也不把存储卡错误码泛化为本次 3 名用户的共同原因。

建议下一步

• 分配给：HarmonyOS 回放页负责人李国涛为主，SDK／服务端负责录像时间轴与在线态的负责人配合；沿用任务 T-20260926-170258-2226，状态保持 P1 / captured。
• 回访 258402、258430、258436／258437，补齐设备 SN、云回放或卡回放类型、设备与服务端在线态、lastHeartTime、p2pLastHeartTime、SD 卡状态、入口时间与页面提示。
• 为回放链路补结构化日志：devId、requestId、入口类型、录像类型、时间轴请求与响应码、ts_AddWatchEx 原始返回、P2P 状态、播放器错误码、首帧耗时、空态原因。
• 修复 ReplayPage.isOffline 的赋值和恢复链路，并让 TSNapi、KMP Video.onError 把原始错误映射为“设备离线／无录像／时间轴失败／存储卡异常／播放器失败”等明确状态，不再只展示通用空白或 video onError。
• 回归矩阵覆盖 HarmonyOS 1.1.1.11 与 1.1.2.3、云回放与卡回放、设备在线与离线、有录像与无录像、SD 卡正常与异常、首帧成功与超时，至少连续切换 10 台设备并执行前后台恢复。

🟠 问题 2：iOS 8.4.1.6 云回放卡顿，首帧与失败状态可能被提前结算 ｜ 负责人：欧阳荣、谭伟

现象与覆盖范围

• 258373：iOS 8.4.1.6、iPhone 系统 16.0.2、山东枣庄，10-19 20:15 反馈“看回放预览卡，监控也一直转圈”。
• 258405、258406：同一用户、iOS 8.4.1.6、iPhone 系统 17.5.1、广东东莞，22:01 与 22:02 连续反馈“APP 卡顿严重／没法观看回放”，按一名独立用户计。
• 258411：iOS 8.4.1.6、iPhone 系统 18.4.1、广东汕头，22:57 反馈“看回放老是卡，应该是这个 APP 有问题”。
• 合计 4 条反馈、3 名独立用户、3 个 iOS 系统版本、2 个省级地区，均发生在 2 小时 42 分钟内，应用版本均为 8.4.1.6。
• 严重度评分：80 / 100。反馈量 20（3～5 条档，按独立用户计）；共性广度 30（跨 3 个系统版本、2 个地区）；业务关键度 30（回放主链路卡顿或不可观看）。
• 去重判定：账本未发现同条件的 iOS KMP 云回放卡顿任务；新建 T-20261020-090554-09c5，状态 P1 / captured。258405 与 258406 只作为一个用户内的连续重复样本，不放大反馈量。

神策证据

• iOS 8.4.106 的 DeviceVideoPlayback 状态字段存在口径矛盾：10-19 有 2,367,187 条记录为 is_success=0 / error_code=0，同时只有 946 条为 is_success=1 / error_code=200。该比例无法当作真实失败率，说明 is_success 与 error_code 的语义或上报链路至少有一侧异常。
• 排除上述 error_code=0 的异常状态后，10-19 仍可观察到明确回放失败：SA106001 获取录像超时 119 次／92 人，SA106006 时间轴为空 71 次／47 人，SA106007 设备离线 54 次／41 人，SA106012 存储卡未初始化 13 次／10 人，SA106010 存储卡不可读写 12 次／11 人，SA106008 无存储卡 11 次／8 人，SA106013 存储卡初始化中 4 次／3 人。
• 同一版本 10-19 的回放 first_frame_time 平均值在 is_success=0 / error_code=0 组为 5,163 ms，最大约 891,929 秒；is_success=1 / error_code=200 组平均 320.7 ms。超长值进一步表明当前 is_success=0 不能直接等价为“未播放”，也不能据此计算真实时长中位数。
• 同期 MonitorFrameResult 的 iOS 8.4.106 每日失败率为 10-13 至 10-19 的 2.64%～2.84%，10-19 为 240,653／9,050,884＝2.66%，没有出现整端断崖。该事件只能说明实时预览大盘稳定，不能排除特定设备、片段或客户端状态机问题。
• 证据边界：DeviceVideoPlayback 没有可用的稳定失败原因关联到反馈 ID；用户所说的“卡”可能表现为长缓冲、首帧未到、音视频中断或页面状态错误，不能只凭失败码指定根因。

Logan 关键日志

• 258373 的 Logan 共 1,877 行，覆盖 20:02:37～20:14:47：
• [L553] 20:05 左右的设备列表响应中，3 台设备均为 devIsOnline=1，可排除“设备统一离线”这一单一路径。
• [L785] 20:05:03 记录“长连接连接失败：未能完成该操作，Socket 未连接”。
• [L795] 20:05:10 记录 CSSLComm:ssl_connect return error -2000002。
• [L1690-L1704] 20:09:08 停止 3 个设备会话。
• [L1792-L1830] 20:14:04～20:14:05 重新获取设备列表、长连接连接成功，耗时 0.4 秒；用户于 20:15:16 提交反馈。
• 日志没有出现 KMPCloudPlaybackVideoView、prepareVideo、playVideo、首帧或播放器错误记录，因此可确认反馈前存在一次长连接和 TLS 异常，但不能证明该异常就是回放卡顿的直接根因。
• 258411 的 Logan 共 3,227 行，覆盖 10:20:04～22:57:47：
• [L345] 10:20 的设备列表响应中设备 devIsOnline=1；[L805-L811] 10:20:48 停止设备会话。
• [L2529-L2532] 22:56:52～53 App 重新启动并初始化，设备仍在线。
• [L3079] 22:56:54 长连接连接成功，耗时 0.4 秒；用户于 22:57:47 提交反馈。
• 同样没有 KMP 回放页、播放器实例、首帧、缓冲、解码或错误码日志，无法判断卡顿发生在时间轴取数、片段解析、首帧等待还是持续播放阶段。
• 258405 与 258406 是同一用户相隔 31 秒的重复反馈，未额外下载第二份相同现场日志；本期 Logan 覆盖 iOS 问题 2/3 名独立用户。

代码定位

• 涉及模块：Seetong-App-iOS/Seetong5.0_ios/Seetong_tps/KMP/View/KMPCloudPlaybackVideoView.m、Seetong-App-iOS/Seetong5.0_ios/Seetong_tps/Classes/TPS/View/IjkPlayerVideoView/IjkPlayerVideoView.m。
• KMPCloudPlaybackVideoView.m:468-486：播放器完成解析后启动 prepared_fallback，固定等待 kKmpCloudPreparedSuccessFallbackDelay 后直接调用 kmp_resolvePendingPlayCallback:YES。
• KMPCloudPlaybackVideoView.m:56：该固定等待只有 1.2 秒；在这 1.2 秒内没有首帧时，KMP 仍会收到 success=true，loading 可以提前结束，但画面尚未被证明可播放。
• KMPCloudPlaybackVideoView.m:870-900：真正的首帧回调能隐藏过渡帧并结算成功；解析完成回调另行启动上述 1.2 秒兜底，两个状态之间没有“已解析但无首帧”的独立中间态。
• IjkPlayerVideoView.m:707-749：IJKMPMovieFinishReasonPlaybackError 与 IJKMPMovieFinishReasonPlaybackEnded 进入同一续播回调分支，没有把错误原因、底层错误码或失败事件传给 KMP 容器。
• KMPCloudPlaybackVideoView.m:829-865：ijkViewPlayEndForPlayer 对首帧前结束按失败结算，但随后无条件发送 kmp_cloud_record_complete_event；该事件语义接近“片段播放完成”，不能区分真实结束与播放错误。
• 调用链：KMP prepareVideo → playVideo → IJK prepareToPlay → 1.2 秒 prepared_fallback 或首帧 → 结束/错误通知 → KMP loading 与续播状态。当前状态机存在“未出首帧但已向业务层成功”和“播放错误被当作结束”的两个可验证风险点。

根因结论

• 置信度：🟡 中。
• 一句话根因：iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。
• 关键证据链：3 名独立用户在同一应用版本、同一晚报告回放卡顿 → 两份 Logan 均证明 App 与设备重连后在线，同时完全没有回放容器日志 → 源码直证无首帧可被 prepared_fallback 标记成功，播放错误被复用正常结束回调。
• 明确不下的结论：不把所有卡顿归因于网络，不把 error_code=0 / is_success=0 的 236 万条样本解释为失败，也不声称已经复现首帧超时。

建议下一步

• 分配给：iOS KMP 云回放负责人欧阳荣为主，KMP 回放页与播放器状态机负责人配合；任务 T-20261020-090554-09c5，状态 P1 / captured。
• 修正首帧门禁：onPrepared 只能表示“已解析”，不能直接成功关闭 loading；以首帧、明确错误或最终超时为互斥终态。若保留兜底，应改为“超时失败并允许重试”，不得发送 success=true。
• 将 IJKMPMovieFinishReasonPlaybackError 拆成独立失败事件，透传 IJK 错误码、片段 URL、devId、请求序号、已播放时长与重试结果；正常结束与错误结束不得共用 kmp_cloud_record_complete_event。
• 在 KMP 桥接层补齐结构化日志：prepareVideo 参数、playVideo 请求序号、onPrepared、首帧耗时、首帧前缓冲时长、每秒播放进度、卡顿时长、播放结束原因、错误码与 loading 状态变化。
• 回归矩阵覆盖 iOS 8.4.1.6、iPhone 系统 16.x／17.x／18.x、云回放与卡回放、正常首帧、解析成功但无首帧、播放中瞬断、设备离线、时间轴为空、连续切片段、前后台恢复，验证无首帧时不会再出现“转圈消失但仍为黑屏或卡顿”。

本期扫描全量

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

反馈接口按 2026-10-19～2026-10-20 日期级查询返回 total=240 / fetched=240 / complete=true，再按 17:08:53～09:00:32 精确裁剪为 123 条。上表按每条反馈的主问题唯一归类，合计 123 条。258436 与 258437、258405 与 258406 分别合并为用户级重复样本，报告中的独立用户数不按提交次数放大。258336 与上一期已分析的 258335 属同一用户、同一 HONOR YAG-W09、同一 Android 8.4.1.6 的连续闪退，按 24 小时去重，仅保留上期任务 T-20261019-171814-47a3。

心愿单、数据源与待补证

心愿单亮点

• 5399：Android 8.4.1.6，希望优化画质，并认为 500 万像素画面与竞品 200 万像素接近；建议由产品与设备成像负责人核对真实清晰度、码率档位和镜头能力。
• 5398：Android 8.3.14.2，反馈“广告太多，关都关不掉”；应与预览或回放广告频控、关闭按钮生命周期和会员豁免策略一并评估。
• 5395／5394：同一用户连续提出远程开关机诉求，可作为设备能力位与控制链路候选需求，不进入缺陷雷达。

数据源状态

• 反馈平台：✅ 正常。日期级 total=240 / fetched=240 / complete=true；精确时间窗内 123 条全部纳入扫描。
• 心愿单：✅ 正常。total=10 / fetched=10 / complete=true。
• 神策：✅ 可查询。DeviceVideoPlayback 与 MonitorFrameResult 均已按平台、内部版本和 is_success 聚合；iOS 回放事件的 is_success／error_code 语义异常已显式降级，不用其计算真实成功率。
• Logan：⚠️ 部分覆盖。iOS 问题 2 的 2/3 名独立用户有日志，均未包含 KMP 回放现场；HarmonyOS 问题 1 的 0/3 名独立用户有日志。
• 代码仓：✅ 正常。已定位 HarmonyOS 回放离线态、AddWatchEx 错误透传和 KMP Video.onError；已定位 iOS 云回放 prepared 兜底、首帧回调与 IJK 错误结束分支。
• 友盟：⏭️ 未作为本期主问题证据。窗口内唯一闪退样本与上期同用户重复，已在上一期核查；两个核心问题均为回放功能异常，不是崩溃率分析。
• TAPD：⏭️ 未调用。本期为功能性根因分析，避免历史 Bug 干扰；任务账本已沿用 T-20260926-170258-2226，并新建 T-20261020-090554-09c5。

待补证

• HarmonyOS 4 条反馈对应的设备 SN、云回放或卡回放类型、服务端在线态、两类心跳、录像时间轴响应、SD 卡状态与端侧 Logan。
• HarmonyOS 1.1.1.11 为何没有稳定的 seetong_app_version 上报；需要核对宿主公共属性与回放事件初始化时机。
• iOS 258373、258406、258411 覆盖进入回放前后的完整 KMP／IJK 日志，以及 prepareVideo、playVideo、onPrepared、首帧、缓冲和 onError 时间线。
• iOS DeviceVideoPlayback 为何出现约 236 万条 is_success=0 / error_code=0，同时只有数百条 is_success=1 / error_code=200；需由埋点 owner 确认字段语义并修复，否则无法可靠量化回放成功率。
• 258449“录像机延时严重”、258438“报警录像突然变暗”、258433“没有声音”、258375“没有 8 点以后的视频”、258365“相册录像无法播放”均为单点或不同症状，本期不合并为同一根因，下一期若同类再现再升级。

下一期 = 第244期 = 2026-10-20-H17.md（今天下午 17:00；窗口 今日 09:00:32～17:00）