Seetong · Report

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

时间窗口：2026-10-24 09:06:54～2026-10-24 17:01:02（Asia/Shanghai）

📌TL;DR 核心要点

  • 🟠 iOS 8.4.1.6 的 NVR 人形报警时间固定快约 60 分钟。反馈 259287 在 12 次前台报警中，App 本地收到时间与推送正文时间稳定相差 3596～3597 秒；同一手机对另一设备的报警时间基本准确，偏差集中在 NVR 19584833。严重度 70 / 100，现象置信度强，根因置信度中，新增任务 T-20261024-170425-9d21。
  • 🟠 跨端 KMP 报警缩略图点击被分流为大图预览，原“点图片看报警视频”的入口退化。反馈 259253 的日志记录 5 次缩略图点击均进入图片预览，没有进入消息整行回放；同一天另有 HarmonyOS 259266 反馈“报警拍的视频怎么成照片了”。严重度 70 / 100，交互回归置信度高，新增任务 T-20261024-170603-cfd1。
  • 反馈 259287：2026-10-24 15:35，iOS 8.4.1.6，iPhone、iOS 18.3.1，广东深圳。反馈原文只有“时间不准确”，但 Logan 和附件日志覆盖了完整故障时段。

🔥最近一个月 Top 问题

按严重度与复发期数排序，已把跨期同类反馈归集；负责人由问题代码锚点对应的 Git 提交历史（blame / 近期主要提交者）反查；数据窗口：最近 30 天（截至 2026-10-24）。

#问题（严重度降序）严重度平台版本负责人问题原因
1HarmonyOS `1.1.2.3` 多用户离线与核心视频链路失效
21 期 · 175 条反馈
100Android · HarmonyOS1.1.1.11 / 8.4.1.6 / 1.1.2.3唐胜、陈宝旺、冉博麟、谭伟HarmonyOS 客户端把 P2P 瞬时离线写成本地持久状态，并在后续在线判断中优先使用这个旧值，可能导致设备已恢复在线却仍显示离线；回放离线态和播放错误透传不足则放大了用户的“看不到画面”体验。
2Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6唐胜、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
3HarmonyOS 画中画状态导致切换设备后仍显示前一路画面
1 期 · 3 条反馈
90HarmonyOS1.1.1.11 / 1.1.2.3张跃译多个 HarmonyOS 画面共享一个无代次、无串行化、无旧控制器清理的 PipManager，切换设备时旧创建任务和新选择竞争，最终把第一路 XComponent、savId 或恢复状态保留下来。
4升级后回放体验整体退化
5 期 · 20 条反馈
85Android · HarmonyOS · iOS8.4.1.6 / 1.1.2.3 / 8.3.14.2唐胜、许源、欧阳荣、谭伟8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
5KMP 回放页未申请屏幕常亮，回放中手机自动息屏
11 期 · 29 条反馈
84Android · HarmonyOS8.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，回放过程中发生系统级息屏。
6Android 实时预览无首帧却被标记为“视频播放中”，并无限重试
5 期 · 12 条反馈
80Android · iOS8.4.1.6 / 8.4.1.4唐胜、张威、谭伟、欧阳荣预览页把“取流请求已提交”或“设备在线状态消息”误当成播放成功，而没有把首帧到达作为唯一成功门禁；add_watch_result=-1 后仍持续 10 秒重试并显示“视频播放中”，导致用户长时间等待且无法获得明确失败反馈。
7SD 卡跌至不可读写或反复未初始化，录像回放被直接阻断
3 期 · 9 条反馈
80Android · HarmonyOS · iOS8.4.1.6 / 1.1.1.11唐胜、张威、陈宝旺设备上报的 SD 卡状态在 258245 中持续处于未初始化／格式化中，在 258173 中由正常可读写跌至不可读写；App 按协议正确展示异常，根因更可能在 SD 卡、卡槽／供电、设备存储控制器或固件挂载逻辑，而不是 KMP 页面误报。
8iOS `8.4.1.6` 云回放卡顿，首帧与失败状态可能被提前结算
2 期 · 8 条反馈
80Android · iOS8.4.1.6 / 8.3.11.3 / 8.4.106陈宝旺、欧阳荣、谭伟iOS 云回放容器允许解析完成后在 1.2 秒无首帧时提前向 KMP 返回成功，同时把 IJK 播放错误与正常结束合并处理，导致页面对真实卡顿、缓冲超时或解码失败缺少准确状态和可回溯证据；这是高度可疑的共同客户端缺陷，但仍需复现确认其是否为 3 名用户的直接主因。
9iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
10Android `8.4.1.6` 在线状态不一致导致卡录像无法打开
1 期 · 1 条反馈
80Android8.4.1.6张威客户端继续使用一份已陈旧约 8 小时的在线缓存，同时又允许单次 P2P 离线事件直接覆盖设备状态；状态模型没有区分云端心跳、P2P 连通和播放出帧，导致用户看到“在线但录像打不开”，且回放页缺少可恢复路径。

🟠 问题 1：iOS 8.4.1.6 的 NVR 人形报警时间固定快约 60 分钟 ｜ 负责人：欧阳荣、许源

现象与覆盖范围

  • 反馈 259287：2026-10-24 15:35，iOS 8.4.1.6，iPhone、iOS 18.3.1，广东深圳。反馈原文只有“时间不准确”，但 Logan 和附件日志覆盖了完整故障时段。
  • 15:28:25～15:33:12 共收到 12 次前台人形侦测推送，全部对应 NVR 19584833 的通道 1、3、6、8。App 本地接推送时间与正文中的时间逐条比较，差值固定为 3596～3597 秒，即正文时间快 59 分 56 秒～59 分 57 秒。
  • 典型样本：App 于 15:28:25.980 收到“大门向东”推送，正文显示 时间(2026-10-24 16:28:22)；App 于 15:33:12.553 收到“后院菜园”推送，正文显示 时间(2026-10-24 16:33:09)。
  • 同一台手机在当天 10:01 和 10:03 收到设备 42767097 的人形报警时，正文时间与本地接收时间只差数秒，说明手机系统时钟、App 日志时区和前台通知回调没有整体偏移。
  • 严重度评分：70 / 100。反馈量 10（1 条直接反馈，但日志内有 12 个同设备连续失败样本）、共性广度 30（iOS、版本、机型、地区四个维度）、业务关键度 30（报警证据时间可信度）。
  • 去重判定：近 24 小时内没有报警时间偏移的雷达问题；10 月 12 日只有一条 Android“监控时间不准确”单点记录，未进入深挖。本期具备原始推送时间与本地接收时间的成对证据，因此新建问题任务。

神策证据

  • 2026-10-24 截至本窗口，CloudPlayback 为 201,700 PV / 92,554 UV，DeviceVideoPlayback 为 14,087,184 PV / 4,221,632 UV。两者只用于说明报警关联的视频业务规模，不能证明报警正文时间是否正确。
  • 今日神策事件清单中不存在 AlarmMessage 事件，现有 SiteMessageClick、CloudPlayback、DeviceVideoPlayback 也没有“报警触发时间与 App 接收时间差”字段。因此本期无法从神策量化同类时间偏移影响面，不能用大盘量级替代报警时间质量。
  • 10 月 17 日至 24 日的 CloudPlayback 日活保持在 12.0 万～13.5 万 UV 的稳定量级，10 月 24 日截至 17:01 为 9.26 万 UV。该稳定性只能说明云端回放业务本身没有被全局中断，不能排除个别 NVR 的时间源或时区配置错误。

Logan 关键日志

  • 反馈 ID：259287。附件 Log0.txt 共 61,683 行，覆盖 10 月 10 日至 10 月 24 日；另有 39,427 行 Logan 覆盖 09:49～15:35。
  • Log0.txt:52216：10:01:04，本地收到设备 42767097 的报警，正文时间为 10:00:59，仅差 5 秒。
  • Log0.txt:60702：15:28:25，本地收到 NVR 19584833-CH-1 的报警，正文时间为 16:28:22，快约 60 分钟。
  • Log0.txt:60726、60729、60730、60731、60739、60741、60744、60745、60746、61070、61074：随后 11 次报警保持同样偏移，排除单次推送乱序。
  • 该日志来自 willPresentNotification，记录的是系统把通知交给 App 的时刻；正文时间已经由推送内容携带。因此至少可以确认，偏差在 App 解析正文之前就已存在，客户端不是把正确的 epoch 时间错误格式化成 +1h。

代码定位

  • 涉及模块：Seetong-App-iOS 的离线报警推送解析与回放定位，以及 Seetong-CliCmpt-Net-Sdk、服务端的报警时间生成链路。
  • AppDelegate.m:604-612：前台推送只读取通知标题和正文，并把正文原样写入日志；当前日志中的 16:28:22 是系统交给 App 的原始展示时间。
  • AppDelegate.m:1134-1157：结构化离线报警路径把 body.alarmTime 当作回放定位的唯一依据，校验通过后直接写入 PushRevMsgModel.alarmTime。
  • UserClient.mm:8742-8751：解析 yyyy-MM-dd HH:mm:ss 时没有显式读取原串的时区偏移，时间串本身也不携带 offset；若上游把设备本地时间或错误时区的格式化时间传下来，客户端无法识别。
  • KMPRouter.m:698：离线报警回放再次把 pushModel.alarmTime 转为时间戳，用于决定报警回放定位位置。时间串快 1 小时会同时影响通知展示、报警列表和回放入口定位。
  • 修复方向锚点：结构化报警 payload 增加可信的 UTC epoch、设备时区偏移、时钟来源和同步状态；客户端优先使用 epoch，禁止对无时区字符串作静默本地化猜测。客户端展示时间与回放定位时间应分别保留“服务端接收时间”和“设备事件时间”，不得混用一个字符串。

根因结论

  • 置信度：现象 🟢 强；固定偏移 🟢 强；偏移发生在 App 收到正文之前 🟢 强；具体应归因于 NVR 时钟、4G 模组时间、设备时区还是服务端序列化 🟡 中。
  • 一句话根因：NVR 19584833 上报的人形报警事件时间比实际时间快约 60 分钟，服务端把该时间直接写入推送正文，App 又把它当作无时区本地时间用于展示与回放定位，最终形成用户可见的报警时间错误。
  • 关键证据链：同一手机、同一 App 对设备 42767097 的时间基本准确 → 对 NVR 19584833 连续 12 次固定快约 60 分钟 → 原始推送正文已带错误时间 → 客户端结构化路径继续用该字符串定位回放。
  • 明确不下的结论：现有日志没有 NVR 系统时间、时区、DST 配置或服务端消费时间，不能判定是设备端快 1 小时，还是服务端按错误时区格式化。不能把问题扩大为“iOS 所有报警时间都错误”。

建议下一步

  • 分配给：欧阳荣复核 iOS 结构化报警时间消费与回放定位；谭伟复核 iOS 时间解析兼容性；服务端报警消息负责人按 NVR ID 19584833 回查事件时间生成链路。
  • 用设备 ID 19584833 回查 2026-10-24 15:28～15:33 的设备心跳、设备时间、时区、DST 状态、报警原始时间和服务端接收时间，确认 60 分钟来自哪一层。
  • 新 payload 明确提供 eventTimeMs、serverReceiveTimeMs、deviceTimezoneOffsetMinutes、timeSource 和 clockSynced。客户端只用 epoch 做回放定位，并把“设备事件时间”和“服务端接收时间”分开显示。
  • 兼容旧文案解析时记录正文原始时间、解析时区、解析后 epoch 与当前手机时间的差值；对超过 5 分钟的报警时间偏差打点，并在回放前给出“设备时间可能异常”的明确提示。
  • 回归设备时钟准确、设备快 1 小时、设备慢 1 小时、设备为半时区、设备开启 DST、跨时区查看六类场景，逐类验证通知正文、报警列表、回放起点与服务端接收时间。

🟠 问题 2：跨端 KMP 报警缩略图点击只打开大图，原视频入口退化

现象与覆盖范围

  • 反馈 259253：11:42，iOS 8.4.1.6、iPhone、iOS 16.6.1、浙江台州。用户明确说“这次版本升级，怎么没有抓拍视频了”，并同时提供 OBS 日志与 Logan。
  • 反馈 259266：13:36，HarmonyOS 1.1.2.3、HUAWEI CRS-AL00、河北邯郸。用户明确说“报警拍的视频怎么成照片了”。
  • 两条反馈都指向“报警卡片原本可看视频，现在只呈现照片”。本期不是把历史 Android 单点直接合并，而是首次拿到 iOS KMP 页面的点击分流日志，并得到 HarmonyOS 同语义样本。
  • 严重度评分：70 / 100。反馈量 10（2 条跨平台直接反馈）、共性广度 30（iOS 与 HarmonyOS、2 个版本、2 个机型、2 个省级地区）、业务关键度 30（报警取证与回放）。
  • 去重判定：10 月 21 日已针对 HarmonyOS 宿主报警桥接丢失视频字段建立 T-20261021-170533-1339。本期继续保留该任务，同时新增 T-20261024-170603-cfd1 跟踪 KMP 缩略图点击语义。两者相关但不是同一层：前者是宿主字段能力，后者是已经确认存在的图片点击分流。

神策证据

  • 神策没有报警卡片媒体类型、缩略图点击目的地或“视频入口是否展示”的事件。SiteMessageClick 只能证明消息被点击，不能区分大图预览和视频回放。
  • 2026-10-24 截至本窗口，CloudPlayback 为 201,700 PV / 92,554 UV，说明云端回放链路仍有持续使用；该数据不能反驳个别报警卡片缺少视频入口，也不能证明受影响用户的视频请求成功。
  • 因此本期影响面由 2 条直接反馈、同一 KMP 页面代码和 Logan 点击链路共同支撑，不把神策业务活跃量当作报警视频入口成功率。

Logan 关键日志

  • 反馈 ID：259253。附件 Log0.txt 共 68,000 行以上，日志从 09:23 覆盖到 11:42 反馈提交前后。
  • Log0.txt:63934-63936：报警时间段存在缩略图请求，说明报警列表确实拿到了图片。
  • Log0.txt:66050-66074：同一设备的报警时间轴存在多条 type = 256、持续 71～87 秒的报警录像段，说明该设备并非完全没有录像数据。
  • Log0.txt:67618-67619、67653-67654、67687-67688、67793-67794、67828-67829：10:31 前后连续 5 次点击缩略图，全部记录为 thumbnail click 和 message thumbnail open preview。
  • 同一日志窗口没有出现 message click open playback，随后都是预览页消失和报警页重新出现，说明用户点图片后得到的是大图，不是视频回放。
  • 反馈 259266 未提供 Logan，但其文字与 259253 的点击结果及 KMP 共享页面行为一致，构成跨端现象证据，不能单独证明 HarmonyOS 宿主视频字段一定完整。

代码定位

  • 涉及模块：seetong-kmp/moduleMessage 的报警列表与 iOS、HarmonyOS 的 KMP 宿主桥接。
  • AlarmMessageViews.kt:976-984：缩略图拥有独立 click 事件，命中后不再向上冒泡到整行点击。
  • AlarmMessagePage.kt:1295-1312：缩略图普通态固定调用 openImagePreviewPage，无论当前报警是否带视频，都只展示图片。
  • AlarmMessagePage.kt:1181-1207：只有整行点击会调用 preparePlaybackNavigation 并进入报警回放。视频入口仍然存在，但与用户过去点击图片的肌肉记忆不一致。
  • AlarmMessagePageViewModel.kt:1253-1258：整行回放只透传 devId、fromAlarmReplay 和 alarmReplayTime，不显式传报警卡片中的 videoLink 或媒体类型；若宿主回放页无法按设备恢复正确录像段，就会进一步放大“只有照片”的感受。
  • 提交 1e420e64：2026-07-27 为缩略图新增独立预览事件，提交说明明确目标是“点击缩略图打开大图”。在该提交之前，页面没有独立缩略图点击处理；从交互路径看，图片点击更容易落到整行播放。该提交与用户“升级后没有视频”的感知高度吻合，是本期最可疑的客户端回归锚点。
  • 修复方向锚点：在缩略图上叠加明确的播放图标；当 videoLink 存在或设备支持卡回放时，单击缩略图直接进入报警视频，图片预览改为长按或次级按钮；纯图片报警则明确显示“仅图片”。若产品决定保留大图单击，必须在卡片上提供独立且醒目的“播放录像”按钮，不能只依赖整行点击。

根因结论

  • 置信度：跨端现象 🟢 强；缩略图点击进入图片预览 🟢 强；报警录像段存在 🟢 强；“所有报警视频均丢失” 🔴 弱。
  • 一句话根因：KMP 报警页把缩略图点击从整行回放中拆分为独立的大图预览事件，用户按原习惯点击报警图片时只得到照片；同时宿主视频字段与回放参数仍存在不完整风险，形成跨端“报警视频变照片”的一致感知。
  • 关键证据链：259253 日志同时证明报警时段存在 71～87 秒录像段和 5 次缩略图点击 → 5 次点击均进入图片预览且没有整行回放 → 1e420e64 代码确实新增了独立缩略图事件及大图预览 → 259266 在 HarmonyOS 上报同一语义。
  • 明确不下的结论：不能仅凭当前证据认定所有云端报警视频 URL 均缺失，也不能忽略 T-20261021-170533-1339 已记录的 HarmonyOS 宿主字段问题。完整根因至少需要拆分“入口分流”和“宿主媒体能力”两层。

建议下一步

  • 分配给：欧阳荣复核 KMP 报警缩略图点击与回放路由；陈宝旺复核 KMP 页面媒体交互约束；HarmonyOS 报警桥接负责人继续推进 T-20261021-170533-1339。
  • 先复现 iOS 259253：分别点击缩略图和整行，核对 thumbnail click、message thumbnail open preview、message click open playback、openPlaybackPage 四条日志及最终页面。
  • 复现 HarmonyOS 259266：抓取同一报警的 thumbnailUrl、videoLink、isCloudReplay、devId、eventTimeMs，区分“有视频但点了图片”和“桥接根本没有视频字段”。
  • 产品先确定交互语义：有视频时缩略图单击应播视频，长按或角标进入图片；没有视频时必须明确提示“仅图片”，不得让用户通过试错判断。
  • 回归云端报警、卡报警、纯图片报警、录像已过期、无回放权限五类场景，每类验证图片存在、视频入口可见、点击后 3 秒内进入播放或给出具体原因三个断言。

全量扫描与数据源

分类与处置反馈数反馈 ID 或说明
🟠 iOS 报警时间固定偏移，进入问题 11259287
🟠 跨端报警缩略图只打开图片，进入问题 22259253、259266
🔁 HarmonyOS 1.1.2.3 离线反馈延续，24 小时内已分析4259251、259270、259295、259300；沿用任务 T-20260926-115214-fdf9
🟡 HarmonyOS 1.1.2.3 刷新、聚焦、摄像头、画面与变焦异常，暂不合并为单一根因6259211、259213、259223、259233、259274、259292
🟡 Android AI、单设备离线、加载与连接单点9259218、259219、259220、259221、259231、259246、259261、259269、259288；AI 信号关联任务 T-20261018-090818-00a1
🟡 更换路由器后无法连接，按配置问题观察1259215
🟢 无效或信息不足3259226、259277、259278
🟣 -102、-101 及等价多语言网络模板71259212、259214、259216、259217、259222、259224、259225、259227、259228、259229、259230、259232、259234、259235、259236、259237、259238、259239、259240、259241、259242、259243、259244、259245、259247、259248、259249、259250、259252、259254、259255、259256、259257、259258、259259、259260、259262、259263、259264、259265、259267、259268、259271、259272、259273、259275、259276、259279、259280、259281、259282、259283、259284、259285、259286、259289、259290、259291、259293、259294、259296、259297、259298、259299、259301、259302、259303、259304、259305、259306、259307
接口在 17:01:02 截止时刻返回 total=98 / fetched=98 / complete=true，但其中 259308 的实际创建时间为 17:01:16，晚于窗口终点；按严格时间过滤后有效反馈为 97 条。上表按主问题唯一归类，合计 97 条。

心愿单亮点

心愿单 ID平台与版本诉求价值判断
5484Android / 8.4.1.6回放时切换摄像头后保留当前时间点⭐⭐⭐ 与今天第251期 NVR 通道切换问题直接呼应，可并入同族回归
5485Android / 8.4.1.6把录像机全部功能放入 App，支持远程操作与配置⭐⭐⭐ 工程运维价值明确，但需按设备能力、权限和误操作保护分阶段实现
5483Android / 8.4.1.6希望通过电视查看家庭画面和活动⭐ 需求描述不足，需先确认投屏、云电视或独立终端中的实际目标

数据源状态

  • 反馈平台：✅ 正常。接口返回 total=98 / fetched=98 / complete=true / pages=2，再按精确时间上界剔除窗口后的 259308，有效扫描 97 条并逐条分类。
  • 心愿单：✅ 正常。total=4 / fetched=4 / complete=true / pages=1。
  • Sensors：⚠️ 部分可用。事件清单、CloudPlayback 和 DeviceVideoPlayback 的八日趋势查询成功；AlarmMessage 事件不存在，query_sql 与分段查询因字段表达式错误返回失败，已停止重试。因此两个问题均不伪造报警媒体成功率或时间偏差率。
  • Logan：⚠️ 部分可用。259287 的附件与 Logan 完整覆盖 12 次 +60 分钟偏移；259253 附件覆盖报警录像段、5 次缩略图预览和未进入回放的结果；259266 未提供 Logan。
  • 友盟：⏭️ 未调用。本期两个核心问题是报警时间与媒体入口，不是崩溃或 ANR。
  • TAPD：⏭️ 未调用。当前没有新的 BUG 单号，使用统一任务账本推进。
  • 代码仓：✅ Seetong-App-iOS、seetong-kmp 已只读定位；KMP 工作区当前无未提交业务改动，iOS 仓库未修改代码。
  • 任务账本：时间偏差新增 T-20261024-170425-9d21；缩略图入口新增 T-20261024-170603-cfd1；HarmonyOS 宿主视频能力沿用 T-20261021-170533-1339。
  • 待补证：需回查 NVR 19584833 的设备时间、时区、DST 与原始报警 epoch；需在 iOS 与 HarmonyOS 分别验证“缩略图点击”和“整行点击”，并采集 259266 的 videoLink、isCloudReplay 与回放路由日志。

下一期 = 第253期 = 2026-10-25-H09.md（明天早上 09:00；窗口 今日 17:01:02～明日 09:00）

🗂️历史期次

查看全部历史期次（近 90 天）→

由 OpenClaw 统一报告渲染器生成 · 最新更新时间：2026-10-24 17:08 · 数据以同名 Markdown 原始报告为准