🎯 Seetong 问题雷达 第259期

🔴 问题 1：Android 8.4.1.6 卡回放时间轴显示不对（NVR 分段比例与刻度换算） ｜ 负责人：陈宝旺、许源

1. 现象与覆盖范围

• 现象：用户在 Android 8.4.1.6 的卡回放页反复反馈「回放时间轴显示不对」「回放时间有问题」，指的不是播放不出画面，而是时间轴本身的刻度或录像色块位置与实际时间对不上。
• 涉及反馈：
• 260052（10-28 11:17，HONOR MEY-AN00，广东，回放时间轴显示不对）
• 260048（10-28 10:59，HONOR MEY-AN00，广东，回放时间有问题）
• 259948（10-27 20:24，HONOR MEY-AN00，广东，公司NVR 70%不出图）——同一台机器、同一 NVR 场景，先报「不出图」再报「时间轴不对」，指向同一设备 260093 语境下的 NVR 通道播放。
• 设备与版本：HONOR MEY-AN00 一台（广东），8.4.1.6；场景为公司 NVR 通道，不是单机摄像机。
• 严重度评分：66 / 100（反馈量 20 ／ 共性 20 ／ 关键度 30）

说明：260052 与 260048 是同一用户、同一台手机、间隔 18 分钟两次提交，按「1 名独立用户 + 2 条重复」计反馈量，不按 2 名用户膨胀。

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

• 事件：DeviceVideoPlayback（回放播放结果）
• 2026-10-27 Android 侧总量 13 806 598 次，其中失败 555 751 次；8.4.1.6 占 11 940 421 次、失败 479 276 次（失败率 4.01%），与 10/24–10/26 的 4.04%、3.97%、3.93% 基本持平，没有恶化拐点。
• 进入场景分布（10-27，Android）：

• 失败错误码 TOP（10-27，Android）：SA106001 154 463 次 / 121 432 人、SA106007 150 311 次 / 112 518 人、SA106006 142 707 次 / 71 793 人。这三类是「取录像失败 / 设备离线 / 超时」语义，不是「时间轴错位」。
• 口径限制（必须写明）：神策当前没有针对「时间轴渲染错位」的埋点（本期查 PlaybackTimeline 事件返回空结果，事件不存在）。所以本条无法用神策量化影响面，只能用自有反馈 + 代码链路判断。这是本期最重要的证据缺口。

3. Logan 关键日志

• 260052 / 260048 的 Logan 下载地址返回 HTTP 401 Unauthorized（本期 6 份候选 Logan 全部 401，见「数据源状态」）。
• 260052 / 260048 的 OBS 附件（seetong_logcat_0..3.log）可下载但四个分片全部为 0 字节——用户上传了附件，但内容为空。
• 259948 的 OBS 附件同样 4 个分片全空。
• 结论：本期拿不到该问题的现场日志。下面的代码判断全部来自源码阅读，未经日志验证，这是置信度只能给「中」的直接原因。

4. 代码定位（详细）

涉及模块：seetong-kmp/modulePlayback（KMP 共享层）+ Seetong-App-Android/…/ui/ext/TimeLine.java（Android 原生时间轴）。

调用链：

PlaybackServiceImpl.parseCloudBaseEvents()        // 服务端 times[]/events[] → TcsEventBean(st, et)
  → PlayBackPageViewModel.buildCardTimelineRecords()   // 事件区间 → TimeLineRecord(startSec, durationSec)
  → CardPlayBackPageTimeline.buildTimeLineSection()    // 传给 KMPTimelineView（原生渲染）
  → KMPTimelineView → Android TimeLine.drawRecords()   // 按 (startsAt - 当天0点) / (当天末 - 当天0点) 映射到像素

两套比例的不一致点：

1. KMP 侧 moduleBase/src/commonMain/kotlin/com/seetong/base/view/TimeLineView.kt:197-198

val recStartPx = (rec.startSec.toFloat() / SECONDS_PER_DAY) * totalW
val recWidthPx = (rec.durationSec.toFloat() / SECONDS_PER_DAY) * totalW

即固定 86400 秒 × 整个 view 宽度。

2. Android 原生侧 TimeLine.java:247-300（drawRecords）

double fb = (OFFSET * mDensScaleFactor) + xb;
double fe = xe - (OFFSET * mDensScaleFactor);
double rb = fb + ((fe - fb) * ((double) (r.startsAt() - t1) / (double) (t2 - t1)));

即先扣掉左右各 16dp 的 OFFSET，再按 时长 / (当天末 - 当天0点) 映射。

当 OFFSET > 0 而 KMP 侧没有扣 OFFSET 时，两条公式在一天的两端会产生固定偏移：越靠近 00:00 和 24:00，色块相对刻度尺的偏差越大；中间段几乎看不出来。这与用户「时间轴显示不对」而非「完全错」的描述一致。

3. 刻度尺本身走的是另一套：TimeLine.timestampToFrameX()（TimeLine.java:381-397）按 mFrameW - OFFSET * 2 缩放，convertPositionToTime()（:571-586）用 mFrameX + OFFSET 做换算。也就是说刻度、色块、游标三者各自有一套坐标基准，任何一个漏改都会表现为「看着对不上」。

4. 时间文本还有一处独立换算：PlayBackPageViewModel.kt:225 与 :2304 在格式化时额外 +8 小时（(timestampMs / 1000 + 8 * 3600) % SECONDS_PER_DAY），而 TimeLineRecord.startSec 传入时没有再减去时区偏移。若服务端 st 是 UTC 秒、KMP 侧按当天秒直接上传，色块整体会偏 8 小时——这条与用户「时间有问题」的表述也很吻合，但本期无日志，无法确认是哪一条。

修复方向锚点（按可疑度排序）：

• TimeLineView.kt:197-198：色块映射是否应与 drawRecords 共用 fb/fe（含 OFFSET）而不是 0..totalW。
• PlayBackPageViewModel.kt:2118 附近 buildCardTimelineRecords 的 startSec 基准，是否与服务端 st 的时区口径一致。
• PlayBackPageViewModel.kt:225 / :2304 的 +8 * 3600 是唯一时区换算点，需确认 TimeLineRecord 是否绕过了它。

5. 根因结论

• 置信度：🟡 中（代码层面存在明确的多套坐标基准，但没有任何本问题的日志或截图，无法指认具体是哪一处偏移）
• 一句话根因：卡回放的时间轴在 KMP 层、原生绘制层、刻度层各自维护了一套「秒 → 像素」换算，且至少有一处未统一 OFFSET 与时区基准，导致色块/刻度在部分区间对不上。
• 关键证据链：反馈（同一用户 18 分钟内两次同诉 + 同一 NVR 场景先报不出图）+ 代码（三套换算基准并存）；神策与 Logan 均未提供证据。

6. 建议下一步

• 分配给：陈宝旺（KMP 时间轴 CardPlayBackPageTimeline.kt / TimeLineView.kt 一手作者，2026-06-25 起多次提交）+ 许源（Android 原生 TimeLine.java owner）
• 优先处理项：

1. 用 260052 同机型同场景复现，抓一张时间轴截图 + 左下角时间文本，先判定是「色块偏移」「刻度偏移」还是「时间文本偏移」。
2. 在 TimelineConfig 上传前打印 records 的前 3 段与后 3 段的 (startSec, durationSec)，并与该 NVR 当天实际录像总时长对数。

• 验证方法：跨零点录像、不足 24 小时录像、满 24 小时录像三类各测 10 次，比对色块起止与 drawRecords 期望像素。
• 任务账本：T-20261028-170859-b7ae（P1，awaiting-approval）

🟠 问题 2：HarmonyOS 1.1.2.3 报警视频入口退化为纯图片 ｜ 负责人：陈宝旺

1. 现象与覆盖范围

• 现象：用户明确说「以前是录像，现在变成图片了」，即报警消息从「可回放视频片段」退化为「只有一张图 / 人形照片」，点开没有视频。
• 涉及反馈（3 条，2 名独立用户）：

• 另有 259923 / 259922（同机型 HUAWEI TLR-AL00，浙江，相隔 2 分钟）报「手机回放没有移动侦测 / 手机上不显示移动侦测」，是同一大类「报警/回放内容缺失」的另一变体，本期作为旁证但不单独深挖。
• 严重度评分：62 / 100（反馈量 20 ／ 共性 20 ／ 关键度 30，取「录像回放」档）

2. 神策证据

• HarmonyOS 1.1.2.3 侧 10-27 DeviceVideoPlayback 9?——本期未单独拉取 Harmony 分端数据，仅拿到全端版本分布中 1.1.2.3 = 992 336 次（10-27 全天，全端），无法做端内失败率对比。
• 与报警内容相关的埋点（报警项是否带 videoUrl）当前没有对应字段，无法用神策量化「视频入口丢失」的比例。
• 结论：本条神策无有效证据，影响面无法量化，只能按反馈原声定性。

3. 代码与历史上下文

• 该问题与既有任务 T-20261021-170533-1339（「HarmonyOS 1.1.2.3 KMP 报警桥接丢失视频能力」）以及 T-20261024-170603-cfd1（「跨端 KMP 报警缩略图点击仅打开图片导致视频入口退化」）高度同源，本期 3 条反馈是同一问题的新增独立用户，不是新问题。
• 相关锚点（沿用两任务已定位的位置）：STAlarmModule.mapAlarmItem、AlarmListBean 的 videoUrl / videoLink / isCloudReplay / canPlayback 透传；1e420e64 引入的独立缩略图点击事件是否吃掉了整行回放入口。
• 本期新增信息（对两个老任务有价值的补充）：三个样本全部是 HarmonyOS 1.1.2.3，且都提到「以前能看录像」——说明不是用户不会用，而是版本行为变化；其中 259957 用词是「只有人形照片」，指向 AI 人形检测报警在 Harmony 侧只拿到缩略图、没拿到视频段。
• Logan：260075/260076/259957 三条都没有 loganFileDownloadUrl（Harmony 侧常见），本期无法验证。

4. 根因结论

• 置信度：🔴 弱（证据只有用户原声 + 既有代码锚点，无本期日志、无神策指标）
• 一句话根因：HarmonyOS 1.1.2.3 报警项桥接层没有完整透传视频字段（或缩略图点击事件截断了回放入口），使报警只剩图片。
• 关键证据链：3 条跨 2 机型 2 地区独立反馈 + 既有任务已定位的桥接字段缺失。

5. 建议下一步

• 分配给：谭伟（Harmony/KMP 报警桥接）+ 陈宝旺（KMP 报警列表）
• 优先处理项：按 T-20261021-170533-1339 的 next_action 继续核对 mapAlarmItem 的 videoUrl/videoLink/isCloudReplay/canPlayback 四个字段，本期补一条要求——必须区分「云端人形报警」与「卡报警」两类分别验，因为 259957 的「只有人形照片」正指向云端人形报警。
• 验证方法：HarmonyOS 1.1.2.3 真机，云端报警 / 卡报警 / 纯图片报警三类各 5 条，确认视频入口可见且 3 秒内能打开。
• 任务账本：本期在 T-20261021-170533-1339 上更新 next_action，不新建重复任务。

本期扫描全量（全部沉淀到知识库）

自有反馈 192 条，其中 130 条为 🟣 普遍网络提示模板（-102 114 / -101 7 / -110003 6 / 10042913 1 / 其他 2），全部为 Android，仅计总量不入雷达。

排除项汇总

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

与既有任务对应、本期新增反馈的问题

其余已归档条目（摘要）

应用市场反馈（2026-10-28 00:00–23:59）

差评原文摘录：本窗口无评论，无可摘录内容。

采集状态：华为、应用宝采集成功但为 0 条；App Store 因 Apple 限流且未配置 ASC Key 失败；Google Play 因未配置代理失败；荣耀、vivo、OPPO、小米四家未导入。以上失败项不代表「用户没有反馈」，仅代表本渠道本期无数据。

心愿单亮点

本期未拉取心愿单（login_and_get_wish_list 不在本期必需的候选池输入中）。但自有反馈里有 6 条同一用户（安徽，HarmonyOS 1.1.2.3，259989～259995）反复要求「识别人脸 / 看清犯罪嫌疑人脸部」，属高价值、可商业化的诉求方向，建议产品侧评估「人脸抓拍 + 人脸比对」能力是否进入规划。

数据源状态

260022 日志解析结论（本期唯一可用 Logan）

260022（OPPO PKU110，日本茨城，国内不能看加载%80，现在国内手机回看没视频）的 4 份 logcat 完整可读，跨 10-27 18:29～19:35：

• 该用户当天多次进入卡回放，DeviceVideoPlayback 全部 is_success=true、error_code=200，其中 19:33:20 一次 connect_type=RELAY、first_frame_time=1814ms、duration=3580ms，首帧 1.8 秒正常出图。
• 全文件检索 SA106* 错误码为 0 次，TPS_MSG_P2P_OFFLINE 为 0 次。
• 结论：该用户在本份日志覆盖时段内回放是成功的，其反馈的「加载 80% 无视频」应发生在这份日志之外（或其日本→国内网络场景下），本期不能用这份日志证明回放失败。这一点必须写明，避免下期误用。

待补证

• 时间轴问题（问题 1）完全没有现场证据：260052 / 260048 / 259948 的 Logan 401、OBS 附件全空。下期需通过客服回访拿到时间轴截图，否则只能停在「代码可疑」层面。
• Logan 平台 401 需排查：本期 6 份候选全部 401，与历史「Logan 可读」不同，怀疑下载鉴权策略或时间窗变更。下期先用 1 份历史可读样本验证链接是否仍有效，再判断是本批问题还是平台问题。
• HarmonyOS 报警视频入口（问题 2）无 Logan：三条样本 loganFileDownloadUrl 全为空，需在 1.1.2.3 灰度批次里主动埋点或让内测同学复现后上传。
• 神策缺「时间轴」埋点：PlaybackTimeline 事件不存在。若问题 1 确认为真实缺陷，建议补一个「时间轴渲染完成 + 首末录像段 startSec/durationSec」的事件，否则同类问题永远无法量化。
• 应用市场侧长期盲区：App Store 未配 ASC Key、Google Play 无代理、四家手商店未导入，需补齐，否则应用市场渠道完全无信号。

下一期 = 第260期 = 2026-10-29-H17.md（明天下午 17:00；窗口 2026-10-28 17:00～2026-10-29 17:00）