🎯 Seetong 问题雷达 第269期

🔴 问题 1：回放「加载不出来」——首次拉取录像列表 15 秒超时后才重试，超大分辨率通道首帧反复失败 ｜ 负责人：唐胜、陈宝旺、张威

1. 现象与覆盖范围

• 现象描述：用户从报警推送或历史事件进入卡回放后，长时间停在加载态，时间轴与录像块迟迟不出现；即使最终出图，画面也会先提示失败再恢复。用户用「加载不出来」「回放不能看」「太卡」来描述，实际卡在进入回放页后的第一次录像列表请求，而不是播放器解码。
• 涉及反馈：回放 / 录像簇 12 条，去重后 10 个用户、11 次提交（262035/262034 为同一用户同一秒重复提交）。其中带有效 Logan 的可完整取证 1 个用户：261988（Android 8.4.2.4、HONOR MTN-AN00、河北沧州，12:42:01「报警消息回放观看打开加载不出来」）。
• 其余同簇反馈（无 Logan，仅作覆盖证据）：262035/262034（HarmonyOS 8.4.2.4、HUAWEI HED-AL00、河北邯郸，16:21:11，「回放不能看」）、261963（HarmonyOS 8.4.2.4、HUAWEI MRT-AL10、河北唐山，11:24:28，「回放太卡了」）、261961（Android 8.4.2.4、vivo V2203A、江苏南京，11:12:32，「拖动卡顿」）、261908（HarmonyOS 1.1.2.3、HUAWEI VYG-AL00、湖北武汉，11-06 22:27:01，「看回放卡的很」）、262044（Android 8.3.2.3、OPPO PFTM10，16:45:15，「没录像」）、262043（Android 8.1.4.4、OPPO PHM110，16:44:39，「这几天为啥没有报警录像呢」）、262025（Android 8.1.5.3、Redmi 24117RK2CC，15:28:15，「四个摄像头都没有录像回放了」）、261827（HarmonyOS 8.4.2.4、HUAWEI，11-06 16:17:13，「查询不到录像」）、261824（Android 8.3.0.7、HUAWEI，11-06 16:14:45，「设备不能回看」）、261956（Android 8.4.2.4、vivo V2571A、云南曲靖，11:04:31，「录像出现大批量以 1 秒的方式存储视频」）。
• 覆盖维度：平台 3（Android / HarmonyOS）、版本 7（8.4.2.4、8.3.2.3、8.3.0.7、8.1.5.3、8.1.4.4、1.1.2.3、1.1.2.3 以下旧包）、品牌 4（HONOR / HUAWEI / OPPO / Redmi / vivo）、地区 6（河北 / 江苏 / 湖北 / 云南 / 山西 / 天津一带）。
• 严重度评分：68 / 100（反馈量 30：24h 内同簇 12 条、去重 10 用户，超过 5 条档；共性广度 20：跨 2 平台 / 5+ 版本 / 4 品牌，达 3 维但症状仍集中在「回放入口不可用」一层；业务关键度 30：录像回放属核心场景但非实时监控）。
• 去重判定：11-03 期（第265期）曾就「多端回放异常」做过现象层归纳，当时明确「待补证：下一期按 clientId 批量查回放事件」但未完成取证；本期用 261988 的完整 Logan 把断点收敛到事件列表请求超时这一具体环节，属推进而非重复，故进雷达并新建任务 T-20261107-170744-d9f3。

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

• 事件量级（近 7 天，DeviceVideoPlayback 全端合计）：11-01 21,214,553 次 → 11-02 20,019,772 → 11-03 20,058,367 → 11-04 20,482,757 → 11-05 20,102,505 → 11-06 20,214,382。总量平稳（日间波动 < 6%），没有出现整体性回放雪崩，说明本问题不是服务端回放能力大面积故障，而是局部链路（超大分辨率通道 + 首次列表请求）的时序问题。
• 版本分布（11-06，DeviceVideoPlayback，Top 6）：Android 8.4.1.6 6,423,603 次、Android 8.4.2.4 6,012,473 次、iOS 8.4.1.6 2,224,032 次、iOS 8.4.106 2,110,660 次、HarmonyOS 8.4.2.4 1,008,022 次、Android 8.3.14.2 704,283 次。本期反馈主力版本 8.4.2.4（Android）正是第二大活跃版本，暴露面真实。
• NVR / 卡回放专用事件近乎不可用：NvrDeviceVideoPlayback 在 11-06 全端仅 32 次（11-01 7 次、11-02 23 次、11-03 12 次、11-04 13 次、11-05 22 次、11-06 32 次），单日不足三位数；而 NvrMonitorFrameResult 11-06 有 25,198 次。这说明「进入卡回放」这个动作本身几乎没有埋点，只有出图性能事件有量。因此无法用神策计算「卡回放入口成功率」，本节不做任何比例推断。
• 待补证：需在 PlayBackPage 的 loadPlaybackData / fetchEventList 两侧补埋「请求发起 / 成功 / 超时 / 重试 / 用户退出」五个事件，并带上 dev_id、is_from_alarm、video_width/height、codec，才能量化本问题。

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

• 反馈 261988（logan/20261107/…40f227bb…log.gz，6,425 行）：
• 进入与首拉（07:24:02）：

07:24:02.312  KMP_SCAN_TRACE-onCreate page=PlayBackPage … {"devId":"24181666-CH-1","fromAlarmReplay":true,"alarmReplayTime":1794007368000}
07:24:02.707  PlayBackPage: loadPlaybackData start, devId=24181666-CH-1, checkSdAbnormal=false, forceRefresh=false, isAutoRetry=false
07:24:02.711  PlayBackPage: fetchPlaybackSdCardInfo start … / skip sd info request, reason=not wifi ipc
07:24:02.756  PlayBackPage: fetchEventList: 从设备服务获取 devId=24181666-CH-1, date=20261107, isToday=true, forceRefresh=false

• 15 秒后超时（同一请求，等了整整 15 秒）：

07:24:17.759  PlayBackPage: loadEventData timeout, auto retry once, devId=24181666-CH-1
07:24:17.760  PlayBackPage: loadPlaybackData start … forceRefresh=true, isAutoRetry=true
07:24:18.212  PlaybackVM: fetchEventList: 设备服务返回 count=15
07:24:23.101  PlaybackVM: fetchEventList: 设备服务返回 count=9

同一设备同一时间在 5 秒内返回 count=15 与 count=9 两套结果，说明首次请求并非失败而是极慢，且重试与首次请求的结果互相覆盖。

• 播放失败与首帧的时序倒挂：

07:24:18.347  RecordPlayerView-startReplay: date=20261107072243, recordType=268435455
07:24:18.641  LibImpl-onNvrReplayResp, act=0, have audio=1, video codec=H265
07:24:18.642  PlayBackPage: receive playback play failed event, devId=24181666-CH-1, result=0
07:24:18.651  onNvrReplayResp-->OpenStreamAgent … videoParam=[codec=H265,width=3840,height=2160,framerate=25,bitrate=2048]
07:24:18.824  onNvrReplayResp-->PlayAgent, ret=0
07:24:18.836  PlayBackPage: receive playback play failed event, devId=24181666-CH-1, result=0
07:24:19.008  RecordPlayerView-onRecvFirstFrame: devId=24181666-CH-1 viewId=29 owner=32139827 isOwner=true

即：SDK 侧 PlayAgent 返回 0（成功）的同时，KMP 页面两次收到「播放失败」事件，随后 167ms 才出首帧。result=0 却被当作失败驱动 UI 状态机，属事件语义错位。

• 每次退出都触发一次无效响应（3 次样本一致）：

07:25:10.234  RecordPlayerView-stopReplay: devId=24181666-CH-1 …
07:25:10.321  LibImpl-onNvrReplayResp, act=0, have audio=0, video codec=
07:25:10.321  EXCEPTION LibImpl-onNvrReplayResp TPS_ReplayDevFileRsp is invalid

12:27:47.185、12:37:50.923 复现同样两行——stopReplay 后 SDK 仍回调一次空参数响应并抛异常。

• 能力集查询超时（与本问题同源，都是「设备服务慢」）：

07:24:17.726  NvrAiSearch: NVR capacity request timed out, nvrId=24181666
07:24:22.780  NvrAiSearch: capacity response, devId=24181666, isChannel=false, responseCode=-10003, data=操作超时，请重试

• 反馈 261961（logan/20261107/…c1b1fa34…log.gz，1,814 行，Error stats: {'-102': 3, 'EXCEPTION': 17}）：该用户 11:10 起只在实时预览里操作（PreviewPlayerView-onRecvFirstFrame: 32731624 两次，均在 1 秒内出图），日志里没有任何 RecordPlayerView-startReplay 或 PlayBackPage 记录，却在 11:12:32 提交「拖动卡顿」。因此这条反馈的「拖动」无法对应到回放链路，本节不把它计入播放器证据（代码层面另有线索，见 4. 中的拖动并发问题）。
• Logan 可用性：本窗口回放簇 12 条反馈中，仅 261988、261961 两份可完整下载；262035/262034/262025/262043/262044/261963/261908/261827/261824 均无 Logan，261956 有 URL 但本窗口未展开分析（时间用于主样本）。

4. 代码定位（详细）

• 涉及模块：
• Seetong-App-Android/Seetong5.0ForSeetong/Seetong5.0（Android 宿主与 SDK 桥接）
• KMP 共享层回放页（日志中的 PlayBackPage / PlaybackVM / RecordPlayerView）——本机仓库内未找到该页 Kotlin 源码（Seetong-App-Android 全仓 grep PlayBackPage / fetchEventList 无命中，kmp/libs/shared-debug.aar 仅 5.4KB 且不含业务类），KMP 源码仓不在标准路径，故本节对 KMP 侧只做行为级定位，不臆造行号。
• 关键类与方法（已核对到源码）：
• kmp/src/main/java/com/seetong/kuikly/export/RecordPlayerView.kt:222-267（startReplay）——ensureReplayAudio → device.m_video = openglesRender → IO 线程 startNvrReplay，失败重试一次后回调 onReplayError
• kmp/src/main/java/com/seetong/kuikly/export/RecordPlayerView.kt:370-383（seekReplay）——每次 seek 都直接下发 NVR_ACTION_SEEK，无节流、无单飞、无上一请求取消
• app/src/main/java/com/seetong/app/seetong/provider/BridgeServiceImpl.kt:1886-1896（startNvrReplay / controlNvrReplay）——直接透传 LibImpl
• app/src/main/java/com/seetong/app/seetong/sdk/impl/LibImpl.java:2251-2285（onNvrReplayResp）——GetProtAgent → OpenStreamAgent → PlayAgent(port, 0)，末尾统一 KuiklyEvent.INSTANCE.sendPlaybackFailedEvent(dev.m_devId, String.valueOf(result))
• lib_base/src/main/java/com/seetong/lib_base/utils/KuiklyEvent.kt:41-50（sendPlaybackFailedEvent）——事件名 kmp_playback_play_failed_event，载荷 {"devId":..,"result":..}
• app/src/main/java/com/seetong/app/seetong/ui/VideoRecordActivity.java:3705-3711——原生侧 TPS_MSG_RSP_NVR_REPLAY 分支同样无条件 sendPlaybackFailedEvent(mFirstDeviceId, String.valueOf(flag))
• 调用链（本问题触发路径）：

PlayBackPage.pageDidAppear → loadPlaybackData → fetchEventList（设备服务取当日录像块，等待上限 15s）→ 超时 → loadEventData timeout, auto retry once → 重试成功 → prepareTimelinePosition → RecordPlayerView.startReplay → BridgeServiceImpl.startNvrReplay → LibImpl.onNvrReplayResp → OpenStreamAgent/PlayAgent →（同时）sendPlaybackFailedEvent(result) → PlayBackPage.receive playback play failed event → RecordPlayerView.onRecvFirstFrame → mark card playback first frame

• 关键分支（哪条路径会踩到）：

1. 首次事件列表请求的等待上限是 15 秒，且超时后才 auto retry once；用户在这 15 秒内看到的就是「加载不出来」。日志中该请求最终返回 count=15，说明设备服务能应答、只是慢。
2. 重试与首次请求无取消关系：07:24:18.212 count=15 与 07:24:23.101 count=9 是两份不同结果，后到者覆盖前者，时间轴与录像块会用哪一份取决于回调顺序。
3. sendPlaybackFailedEvent 的 result 语义不统一：LibImpl.onNvrReplayResp 末尾传的是 result（解码/开流结果），VideoRecordActivity 传的是消息 flag；两者为 0 时下游仍按「失败」处理，于是出现「PlayAgent ret=0」与「play failed result=0」并存。
4. TPS_ReplayDevFileRsp is invalid 在 stopReplay 后必现，属退出时的空响应，会额外产生一次失败事件与一次异常上报，抬高同类问题的日志噪声。
5. seekReplay 无节流：拖动条每次滑动都可能下发一次 NVR_ACTION_SEEK，在 4K 通道（3840×2160@25fps、bitrate=2048）上叠加大量在途开流请求，与 261961「拖动卡顿」的体感方向一致（该反馈因未进入回放页无法直接证实）。

• 修复方向锚点：
• 事件列表首次请求等待上限由 15s 下调到 3~5s，超时先渲染「历史录像块」骨架 + 「正在加载更多」占位，避免整页空白；
• loadPlaybackData 的重试与首次请求改为单飞 + 可取消，迟到的响应按请求序号丢弃；
• KuiklyEvent.sendPlaybackFailedEvent 调用点统一语义（失败才发，或增加 code 字段区分「开流结果」与「失败原因」），KMP 侧对 result=0 不做失败态切换；
• stopReplay 后对 TPS_ReplayDevFileRsp is invalid 做静默处理，不再抛异常；
• seekReplay 增加 200~300ms 防抖与单飞，拖动中只保留最后一次目标时间；
• 4K/H265 通道回放前预置解码参数、延长首帧门禁窗口，并记录 open→PlayAgent→firstFrame 分段耗时。

5. 根因结论

• 置信度：🟡 中
• 一句话根因：回放页把「首次拉取录像列表」的等待上限设为 15 秒且超时后才重试，重试与首次请求互相覆盖；同时 SDK 开流成功与失败事件共用 result=0，导致页面先进入失败态再出首帧——用户看到的就是「加载不出来」。
• 关键证据链：Logan 中 07:24:02.756 发起 → 07:24:17.759 超时（正好 15 秒）→ 重试后 count=15/count=9 两份结果 + onNvrReplayResp 打印 video codec=H265 3840×2160 与 PlayAgent ret=0 + 同刻两次 play failed result=0 + 167ms 后 onRecvFirstFrame（客户端时序事实）；NvrAiSearch 同设备同刻也出现 capacity request timed out 与 -10003 操作超时（同源「设备服务慢」的旁证）；神策 DeviceVideoPlayback 总量平稳（排除服务端整体故障）。未能拿到：事件列表请求在服务端/设备侧的实际处理耗时，故「为什么慢」仍待设备服务侧确认。

6. 建议下一步

• 分配给：KMP 回放页负责人（PlayBackPage / PlaybackVM 源码仓需先确认位置，RecordPlayerView.kt 历史提交为 sheng.tang、xuyuan）；SDK 桥接侧 LibImpl.onNvrReplayResp 与 KuiklyEvent 口径由 张威（SDK owner）与 Android 客户端共同确认。
• 优先处理项：

1. 15 秒等待 + 重试覆盖 → 3~5 秒 + 骨架屏 + 单飞可取消；
2. result=0 不再驱动失败态，stopReplay 后的 invalid 响应静默；
3. seekReplay 防抖单飞（4K 通道尤其需要）。

• 验证方法：同一 NVR 通道从报警推送进入卡回放 20 次，验收标准为时间轴 3 秒内可见、首帧 3 秒内出现、全程无 play failed 事件；再覆盖 4K/1080P 两种分辨率 × 正常/弱网各 10 次，并回归 261961 的拖动场景（连续拖动 30 次不出现卡死）。

🟠 问题 2：HarmonyOS 端回放事件量一夜掉九成，只剩 8.4.2.4 单版本支撑 ｜ 负责人：陈宝旺

1. 现象与覆盖范围

• 现象描述：HarmonyOS 端用户反馈「回放不能看」「看回放卡的很」「查询不到录像」，同时神策显示该平台回放事件在 11-04 到 11-05 之间一夜之间断崖式下跌，主力旧版本 1.1.2.3 的事件量从日均 54 万级跌到 5 万级。
• 涉及反馈：HarmonyOS 回放反馈 4 条 / 4 个用户（无重复）：262035、262034（同一用户同一秒重复提交，计 1 个用户，HUAWEI HED-AL00、8.4.2.4、河北邯郸，「回放不能看」）、261963（HUAWEI MRT-AL10、8.4.2.4、河北唐山，「回放太卡了」）、261908（HUAWEI VYG-AL00、1.1.2.3、湖北武汉，「看回放卡的很」）。
• 覆盖维度：平台 1（HarmonyOS）、版本 2（8.4.2.4、1.1.2.3）、品牌 1（HUAWEI，4 个机型 HED-AL00/MRT-AL10/VYG-AL00）、地区 3（河北邯郸 / 河北唐山 / 湖北武汉）。
• 严重度评分：64 / 100（反馈量 10：24h 内 4 条、去重 3 用户，属 1–2 条档位但同平台同现象连续出现；共性广度 20：2 版本 / 3 机型 / 3 地区，达 2 维；业务关键度 30：回放属核心场景但非实时监控）。
• 去重判定：与问题 1 的区别是证据类型不同——问题 1 是个体时序（Logan 级），本问题是平台级分布（神策级）。三条反馈均无 Logan，无法做个体取证，故单列并从分布侧立论，新建任务 T-20261107-170750-5c77。

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

• DeviceVideoPlayback 按 $os = HarmonyOS 拆版本（11-04 → 11-06）：

• 判读（严格区分已证与未证）：
• 已证：1.1.2.3 的断崖发生在 11-04 → 11-05 一夜之间，不是渐进衰减；同期 8.4.2.4 几乎等量上升（+43 万 vs −45 万），形态上更像版本迁移而非「回放功能整体挂掉」；8.3.14.2/8.3.13.3/8.3.8.4 三个旧版本完全持平，说明不是服务端一刀切关闭旧版本。
• 未证：无法从神策判断这是「用户主动升级」还是「旧包被强制下线/引导升级失败」。若是后者，1.1.2.3 剩下的 5.2 万次事件可能代表卡在升级中间态的存量用户，其回放入口状态需实际验证。
• 不能做的事：不能由「事件量下降」直接推断「回放不可用」——两种解释（迁移完成 vs 入口断裂）在数据上同形。
• 版本画像：8.4.2.4 已成为 HarmonyOS 端绝对主版本（11-06 占该平台 DeviceVideoPlayback 的 86.9%），1.1.2.3 残余量占 4.6%。
• 待补证：需要鸿蒙端「安装量 / 启动量 / 升级弹窗点击」三个事件，才能把「事件量下降」拆分为「用户数下降」与「人均回放次数下降」；当前只能看到事件次数。

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

• 本问题 4 条反馈全部无 Logan（262035、262034、261963、261908 的 loganFileDownloadUrl 均为空串），符合 skill 已记录的「HarmonyOS 反馈常不提供日志」特征。
• 唯一可用的间接证据来自 Android 同族实现：问题 1 的 261988 日志中，PlayBackPage 的 loadEventData timeout 与 NvrAiSearch capacity request timed out 同刻出现，说明「设备服务慢」会同时打击事件列表与能力集查询；HarmonyOS 端若走同一 KMP 回放页，理论上会踩同一个 15 秒等待分支，但本节不据此断言，需真机取样。
• 结论：本问题当前为分布证据驱动，个体机制待补。

4. 代码定位（详细）

• 涉及模块：HarmonyOS 端回放（~/Seetong-App-Harmony 未在本机标准路径下，代码待定位）＋ KMP 共享回放页（同问题 1，源码仓位置未知）。
• 可确认的交叉点：HarmonyOS 端 8.4.2.4 与 Android 端 8.4.2.4 共用 KMP 回放页（PlayBackPage），而问题 1 已证实该页存在「首次列表请求 15 秒等待 + 重试覆盖」与「result=0 误判失败」两处机制。若鸿蒙使用同一份 KMP 代码，则用户感受到的「回放不能看 / 太卡」很可能同源。
• 搜索路径（已尝试，均无结果）：~/Seetong-App-Harmony（不存在）、/Users/topsee/Seetong-App-Android 全仓 grep PlayBackPage/fetchEventList（无命中）、kmp/libs/shared-debug.aar（5,484 字节，仅 classes.jar 桩，不含业务类）。
• 修复方向锚点：先确认鸿蒙端回放入口与 KMP 版本绑定关系；若共用，问题 1 的修复可直接覆盖；若不共用，需单独核对鸿蒙端「录像列表请求等待上限」与「播放失败事件消费」两处。

5. 根因结论

• 置信度：🟡 中（分布证据清晰，但缺个体机制与日志）
• 一句话根因：HarmonyOS 端回放主力从 1.1.2.3 向 8.4.2.4 迁移，迁移窗口内旧版本事件量断崖（−90%）、新版本承接（+91%），而迁移过程中仍有用户在旧版本提交「回放不能看」，需确认是迁移未完成还是升级后回放入口异常。
• 关键证据链：神策按版本拆分的一夜断崖与等量承接（已证）＋ 4 条鸿蒙回放反馈集中在同一周内且横跨新旧两个版本（用户事实）＋ 问题 1 已证实 KMP 回放页存在 15 秒等待与失败态错判（机制事实，可复用但未经鸿蒙真机验证）。未证：迁移是主动还是被动、旧版本残余用户的实际回放能力。

6. 建议下一步

• 分配给：HarmonyOS 端负责人（回放入口与版本迁移策略）；若确认共用 KMP 回放页，则与问题 1 同一负责人合并处理。
• 优先处理项：

1. 核对 11-04→11-05 是否发生版本强制升级、旧包下线或商店下架；
2. 抽 3 台 1.1.2.3 存量设备，确认升级路径与升级后回放入口是否可用；
3. 若确认共用 KMP 回放页，直接复用问题 1 的三项修复。

• 验证方法：升级弹窗曝光→点击→安装完成→进入回放全链路，在 1.1.2.3 → 8.4.2.4 的真实升级设备上各跑 10 次，验收标准为升级后首次进入回放 3 秒内出时间轴；同时回访 262035、261963、261908 三位用户。

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

1. 回放 / 录像异常（回放不能看、加载不出来、拖动卡顿、没录像、1 秒片段、查询不到录像）：12 条，去重 10 用户 / 11 次提交 → 🔴 进雷达，详细分析见问题 1。
2. HarmonyOS 回放事件量断崖：4 条反馈 + 平台级神策下降 → 🟠 进雷达，详细分析见问题 2（与第 1 项部分重叠，从分布侧独立立论）。
3. 网络通用（-102 / -101 / 多语言网络模板 / 网络不稳定提示）：270 条 → 🟣 网络问题，已排除（普遍类，HTML 自动折叠）。
4. 设备离线 / 掉线 / 画面断开：7 条（去重 6 用户）→ 🟡 配置问题，已排除。261751、261813 已由第268期任务 T-20261106-170959-18b8 覆盖；本期新增 261973 已单独建单 T-20261107-170803-b781，不在本期展开。
5. 实时画面看不了、加载不出图、登录、广告与心愿单类：26 条 → 🟡 配置问题，已排除。其中 261844/261843 为同一 OPPO 用户重复提交且呈间歇性；261886/261885 重置密码已由 T-20261015-090316-0dda 覆盖；262046 广告关闭已由 T-20261106-171003-2e2f 覆盖；262045 积分商城消失、262022 充值失败属商业化配置，转运营；261850 大字号、261735 报警页卡顿已由 T-20261027-171006-ff51 覆盖。
6. 其他 / 无效内容（单字、纯号码、重复提交、格式咨询）：4 条 → 🟤 心愿单建议，已排除。含 262047「关闭」、262042「卡」、262028「有问题」、261859「连」、261806/261805「高」、261904/261903/261779/261778/261777 纯号码、261871 格式化流程咨询、261982 版本更新提示、261998 网络故障文案、261919/261918/261920/261930 设备与网络质量。

合计：12 + 4 + 270 + 7 + 26 + 4 = 323 条（含 #1 与 #2 重叠的 4 条重复计入），去重后 319 条，与 fetched=319 对齐。

说明一：#1 与 #2 存在 4 条重叠（鸿蒙回放反馈），#2 在合计中单列是因为它带了平台级神策证据，不能并入 #1 的计数口径——两段在正文各自独立立论，不重复计入「进雷达」的总数 2。

说明二：分类按「一条反馈归一个主类」统计，同一条含多个关键词时取业务影响更高的一类。

应用市场反馈（2026-11-07 00:00–23:59）

• App Store：0 条评论 / 0 差评 → 无评论，不参与打分。
• 华为应用市场：0 条评论 / 0 差评 → 无评论，不参与打分。
• 应用宝：0 条评论 / 0 差评 → 无评论，不参与打分。
• Google Play：采集失败 → 本机网络不可达，未配置代理。
• 荣耀 / vivo / OPPO / 小米：待导入 → 本窗口无导入文件，需开发者后台人工导出。

差评原文摘录：本窗口无采集到任何评论，无原文可摘。

采集状态：App Store 自动抓取 0 条（RSS 上限 500 条）；华为应用市场 0 条；应用宝 0 条；Google Play 采集失败（未配置代理）；待导入：荣耀应用市场 / vivo 应用商店 / OPPO 软件商店 / 小米应用商店（inbox 无导入文件）。原始数据：knowledge/appstore-feedback/raw/2026-11-07.json。应用市场侧本窗口为大部分盲区，不能等同于「无差评」。

数据源状态

心愿单亮点（本期）

• 5742｜Android 8.4.2.4｜建议与飞牛 NAS 联动，用 NAS 充当录像存储｜⭐⭐⭐ 用户主动提出存储侧对接方案，与自己搭 NVR 的用户群高度重合，可作为「本地存储扩容」方向的输入。
• 5741｜Android 8.4.1.6｜希望一键保持通话对讲，不用一直按住｜⭐⭐ 对讲交互老诉求，实现成本低（长按改开关 + 状态提示），可放近两个版本。
• 5737｜HarmonyOS 8.4.2.4｜「现在为什么看回放这么卡？或者说根本看不了回放」｜⭐⭐ 与本期问题 1/2 同一痛点的用户原声，可作为修复后的回访对象。
• 5738｜Android 8.4.1.6｜只能看照片不能看视频｜⭐⭐ 可能是回放入口能力位判断问题，建议与问题 1 一并核查。
• 5727｜Android 8.4.2.4｜几个摄像头无缘无故离线，「用不起」｜⭐⭐ 与离线簇同源，反映用户对离线无提醒、无自检的不满。
• 5726｜Android（版本未标）｜最多 100 个摄像头太少，几百个摄像头要开多个账号｜⭐⭐ 工程商场景的账号容量诉求，需产品与计费侧共同评估。
• 5734｜iOS 8.4.1.6｜希望有清除缓存的页面｜⭐ 低成本易用性补齐，可与设置页一起排期。

待补证

• 问题 1 的设备服务耗时未拿到：「为什么首次列表请求要 15 秒」目前只有客户端侧证据（loadEventData timeout 恰好在 15.000s、NvrAiSearch -10003 操作超时）。需设备服务侧提供同一 24181666-CH-1 在 11-07 07:24 的录像索引查询耗时与排队情况。
• 问题 1 的 KMP 源码仓位置未知：PlayBackPage / PlaybackVM 不在本机任何一个标准仓库内（shared-debug.aar 只有 5.4KB 桩），本期只能做行为级定位，无法给出行号级锚点，影响负责人反查精度。
• 问题 2 的迁移性质未确认：神策只能证明 1.1.2.3 事件量一夜下降、8.4.2.4 等量承接，无法区分「用户主动升级」与「旧包被下线」。需要鸿蒙端安装量/升级弹窗数据，以及 3 台存量设备实测。
• 鸿蒙 4 条反馈全部无 Logan：262035/262034/261963/261908 均未上传日志，问题 2 缺个体机制证据；建议鸿蒙端在进入回放页时强制补采一次日志快照。
• 「录像被切成大量 1 秒片段」未展开：261956（vivo V2571A、8.4.2.4）有完整 Logan 与打包日志但本期时间用于主样本，属设备端录制策略问题，建议下期优先取证。
• 应用市场盲区：Google Play 采集失败、四个手商店未导入，App Store/华为/应用宝本窗口为 0 条，跨渠道共现无法验证。

下一期 = 第270期 = 2026-11-08-H17.md（明天下午 17:00；窗口 2026-11-07 17:00 ~ 2026-11-08 17:00）