Seetong · Report

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

时间窗口：2026-10-17 17:00:00 ~ 2026-10-18 09:00:21（Asia/Shanghai）

📌TL;DR 核心要点

  • 🔴 远程视频与回放链路再次多点失败，本窗口 6 条独立反馈，覆盖 Android、HarmonyOS、4 个版本、6 个机型、4 个省级地区，严重度 90 / 100，根因置信度弱。Android 反馈 257947 的 Logan 直证：P2P 连接在线、两次 AddWatch 均已发起，但约 10 秒内始终没有首帧，埋点明确记录 isPreviewSuccess:false；界面却提前显示“视频播放中”。HarmonyOS 的 4 条均无 Logan，仍无法与设备离线、录像为空或播放组件失败区分。沿用任务 T-20260923-170444-60dc、T-20260926-170258-2226。
  • 🟠 iOS 8.1.2.4 微信登录服务端返回 30100225 授权码校验失败，本窗口 2 名独立用户，严重度 80 / 100，置信度中。两份 Logan 都显示请求携带了非空微信授权码，并在短时间内重复提交同一 code；同一 code 被服务端拒绝后，客户端没有清理授权态或重新拉起微信授权。新建任务 T-20261018-090804-7ee8。
  • 257896：HarmonyOS 1.1.2.3、HUAWEI PLR-AL00、河北石家庄，反馈“查看回放卡顿就卡住，画面不动了”。

🔥最近一个月 Top 问题

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

#问题（严重度降序）严重度平台版本负责人问题原因
1Android 8.4.1.6 及 HarmonyOS 1.1.1.11 单设备随机离线、P2P 恢复失败
16 期 · 145 条反馈
100Android · HarmonyOS1.1.1.11 / 8.4.1.6 / 1.1.1陈宝旺、冉博麟、唐胜、李国涛257582、257639 已确认是服务端心跳长期停更并伴随 P2P 离线，App 只是按离线状态展示；问题更可能在设备端、设备网关／P2P 服务或固件恢复机制，而不是 Android 播放器单点故障。
2Android 与 iOS 8.4.1.6 报警功能突然失效与通知不达
1 期 · 3 条反馈
90Android · iOS8.4.1.6陈宝旺、许源现有客户端样本表明 Android 通知权限与 token 注册均成功，故障更接近“服务端未生成报警或推送任务未送达”，但神策缺少报警生成与推送到达事件，iOS 样本又混合了通知权限关闭，当前不能完成单点定因。
3升级后回放体验整体退化
4 期 · 18 条反馈
85Android · iOS8.4.1.6 / 8.3.14.2唐胜、许源、欧阳荣、谭伟8.4.1.6 对回放链路做了多处改动（时间条 UI、通道切换进度对齐、报警-录像联动），导致回放体验多点退化；Logan 显示取流层无崩溃，问题在"UI/状态对齐 + 报警录像关联"而非连接失败。
4KMP 回放页未申请屏幕常亮，回放中手机自动息屏
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，回放过程中发生系统级息屏。
5iOS 8.1.2.4 微信登录授权码重复提交触发 30100225
1 期 · 3 条反馈
80iOS8.1.2.4 / 8.1.204 / 8.4.106待定微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
6iOS 老版本微信登录空授权码触发 30100222
1 期 · 1 条反馈
80iOS8.1.3.5 / 8.1.305 / 8.1.503位冬微信授权回跳在当前旧版 iOS 上返回了空 code，客户端没有把它视为失败边界，仍向服务端提交空授权码，最终稳定触发 30100222。
7KMP 卡回放取「当天录像」时走云回放分支，失败后无超时兜底并反复重试
1 期 · 4 条反馈
71Android8.3.11.3 / 8.4.1.6陈宝旺、谭伟KMP 回放页在选择 Tab 时只信设备记忆、不信设备能力，把 supportCloud=false 的设备硬切到云回放 Tab 并以「前一天」初始化；云链路从未 prepared（currentVideoUrl 空、cloudPrepared=false），失败事件 result=0 又恰好落入 result<0 的无退避重试分支，同时 SD 异常态在非 WiFi IPC 上被 return NONE 吞掉——三者叠加，用户既看不到当天录像也收不到失败提示，且失败状态被 saveLastPlaybackTab(tabIndex=1) 固化到下一次。
8iOS 8.4.1.6 冷启动点击离线报警推送后未进入回放
1 期 · 2 条反馈
70iOS8.4.1.6 / 8.4.106欧阳荣、谭伟、陈宝旺当前冷启动没有留下通知响应回调或 KMP 回放路由证据，用户实际停留在普通启动链路；最可能的缺口是冷启动通知回调 / 参数分支未被当前处理逻辑承接或没有兜底，但尚不能确认是 APNs payload 缺 content、回调未到、视图条件拦截还是路由失败。
9Android 8.4.1.7 KMP 回放页关闭窗口无效
1 期 · 1 条反馈
70Android8.4.1.6 / 8.4.1.7唐胜、陈宝旺当前只能确认 KMP 回放页成功创建并出流、用户随后进入其他页面，无法确认关闭请求是否到达 closePage；最可疑点是关闭桥接缺少结果反馈，以及返回键存在双重消费路径，但尚未形成直证。
10iOS 灯光配置「提示失败 / 实际成功」——`NetworkIndicatorEnable="-1"` 非法值导致 1521 返回 -1
1 期 · 3 条反馈
68iOS8.4.1.4 / 8.4.1.6欧阳荣、谭伟iOS 端把 1301 + 1108 + 1521 三条独立协议的结果汇聚到同一个回调 block（UserClient.mm:1504 / 5091 / 5099），任一条失败即判定整次保存失败；当 1521 携带设备并不支持的 NetworkIndicatorEnable="-1" 字段时返回 Result="-1"，UI 因此报「配置失败」，而 1301 / 1108 已生效 → 用户看到「提示失败、实际成功」。

🔴 问题 1：跨端远程视频与回放入口多点不可用 ｜ 负责人：李国涛、唐胜、谭伟

1. 现象与覆盖范围

  • 257896：HarmonyOS 1.1.2.3、HUAWEI PLR-AL00、河北石家庄，反馈“查看回放卡顿就卡住，画面不动了”。
  • 257917：HarmonyOS 1.1.1.11、HUAWEI SGT-AL10、河北邯郸，反馈“不能看了”。
  • 257945：HarmonyOS 1.1.1.11、HUAWEI SCA-AL00、贵州六盘水，反馈“太卡了打不开”。
  • 257947：Android 8.4.1.6、OnePlus PLC110、辽宁沈阳，反馈“视频打不开”，有 Logan。
  • 257987：HarmonyOS 1.1.1.11、HUAWEI ALN-AL10、河北廊坊，反馈“没有回放”。
  • 257991：Android 8.3.14.2、vivo V2309A、山东枣庄，反馈“怎么没有回放了”，有 Logan。
  • 严重度评分：90 / 100。
  • 反馈量 30：同一窗口 6 条同域反馈，超过 5 条档。
  • 共性广度 30：覆盖 2 个平台、4 个版本、6 个机型、4 个省级地区。
  • 业务关键度 30：实时预览与录像回放均属安防核心能力；按回放口径取 30 分。
  • 证据边界：6 条反馈的症状并不完全一致，不能据此认定是同一个客户端缺陷。当前可以确认的是“多入口不可用”这一用户侧现象，以及跨端都存在首帧失败不可见、失败原因不可回溯的问题。

2. 神策证据

  • 反馈平台版本与神策版本并非同名：Android 8.4.1.6 直接对应 $app_version=8.4.1.6；Android 8.3.14.2 直接对应 8.3.14.2；HarmonyOS 1.1.1.11、1.1.2.3 在神策当前运行口径中分别映射到 8.4.1.6、8.3.14.2。
  • MonitorFrameResult 在 2026-10-17 的当前版本失败率：
  • Android 8.4.1.6：失败 929,536 / 总计 33,624,158，2.76%。
  • Android 8.3.14.2：失败 114,806 / 总计 3,930,557，2.92%。
  • HarmonyOS 8.4.1.6：失败 204,964 / 总计 8,391,513，2.44%。
  • HarmonyOS 8.3.14.2：失败 7,588 / 总计 266,258，2.85%。
  • MonitorFrameResult 平台级趋势没有出现整端崩塌：Android 近 7 天失败率约 2.67%～2.84%，HarmonyOS 约 2.42%～2.54%；10 月 18 日至查询时刻分别为 Android 2.23%、HarmonyOS 1.97%。这与“少数用户命中失败路径”相符，不支持“所有用户都无法看视频”的结论。
  • DeviceVideoPlayback 在 2026-10-17 的平台失败率：Android 649,694 / 15,571,725，4.17%；HarmonyOS 10,021 / 243,216，4.12%。10 月 11 日至 16 日 Android 约 3.93%～3.96%、HarmonyOS 约 3.68%～3.91%，10 月 17 日均有约 0.2～0.4 个百分点的上升。
  • 10 月 18 日截至当前时刻，DeviceVideoPlayback 失败率继续偏高：Android 175,326 / 3,400,466，5.16%；HarmonyOS 2,783 / 53,628，5.19%。这是不完整自然日，不能直接外推全天，但值得继续观察。
  • 服务端字段限制：本次查询未返回可用的 fail_reason 明细，无法计算“设备离线、录像为空、首帧超时、存储卡异常”各占多少，只能使用平台与版本级失败率。

3. Logan 关键日志

  • 反馈 257947 的 Logan 共 11,763 行，覆盖 2026-10-17 01:10 至 21:14。
  • [L11232-L11233]：21:11:00 收到 P2P 连接响应，TPS_MSG_P2P_CONNECT_OK，说明当前不是简单的设备离线前置失败。
  • [L11253-L11256]：addWatch 记录旧状态 m_add_watch_result=-1，随后发起拉流，日志文字中的 ret:0 只代表本次调用返回，并未代表首帧成功。
  • [L11263]：SDK 的 TPS_AddWachtRsp.nResult=0，连接和开流请求被接受。
  • [L11289-L11297]：同一通道再次收到开流响应，甚至出现 device playing, stop it，说明 10 秒求流循环已经开始与原请求叠加。
  • [L11257]：21:11:00.685 界面已经把状态写成“视频播放中”，此时尚未收到首帧。
  • 到 21:11:08 用户切走前，日志没有目标通道的 onRecvFirstFrame。
  • [L11380]：结束预览时埋点明确记录 isPreviewSuccess:false, isOnline:true, getPreviewDuration:10199，即设备在线、停留约 10.2 秒、仍未成功出图。
  • 用户在 21:11:36 提交反馈，与上述失败时段吻合。
  • 反馈 257991 的 Logan 共 7,496 行，07:10:25 启动并成功获取设备列表，07:23:43 后直接进入 07:24:11 的反馈上传；反馈前没有覆盖到 RecordPlayerView、回放请求或回放首帧记录。该条只能证明用户提交了“没有回放”，不能证明本次会话曾实际进入回放页。
  • 257896、257917、257945、257987 均为 HarmonyOS，loganFileDownloadUrl 全部为空，无法给出类名、错误码和状态机分支。

4. 代码定位

  • Android 预览入口与状态显示
  • PreviewPlayerView.kt:427-569：playVideo 先设置 PlayState.LOADING，再调用 iPlayerController.startPlay；随后无条件执行 clearVideoInfo()。
  • PreviewPlayerView.kt:640-642：clearVideoInfo() 固定设置 video_play_tip，中文资源值为“视频播放中”。
  • PreviewPlayerView.kt:950-976：真正的成功状态只在 onRecvFirstFrame 中设置；因此当前顺序会让“尚未收到首帧”的页面提前显示播放成功。
  • PreviewPlayerView.kt:761-835：10 秒求流定时器在无首帧时反复停止再开流，但没有单独的“首帧超时”页面状态或错误原因。
  • LibImpl.java:1468-1544：addWatch 返回 SDK 调用结果并写入 m_add_watch_result；异步 TPS_AddWachtRsp 与首帧是后续事件。现有日志已经出现“调用返回 0、首帧未到”的合法中间态，调用方不能把 ret=0 当作播放成功。
  • HarmonyOS 回放入口
  • ReplayPage.ets:155：isOffline 只有声明，后续未找到在设备在线态或连接失败时赋值的路径。
  • ReplayPage.ets:3875-3898：卡回放页只有在 isOffline=true 时才显示“设备离线”提示，所以该提示在当前状态下无法可靠触发。
  • DeviceServiceImpl.ets:5533-5548：ts_AddWatchEx 最终只返回 ret == 0，没有把失败码、连接类型或首帧超时传给回放页。
  • KMPCloudPlaybackVideoView.ets:70-78：播放器 onError 只向页面发送固定字符串 video onError，原始错误码被丢弃。
  • KMPCloudPlaybackVideoView.ets:191-209：准备失败和播放失败回调只带通用 message，前端无法区分无录像、设备离线、网络失败和播放器解码失败。

5. 根因结论

  • 置信度：🔴 弱。
  • 已确认事实：Android 257947 在设备在线、P2P 与 AddWatch 请求均被接受的情况下，10.2 秒内没有首帧，并且页面提前显示“视频播放中”。
  • 跨端共同缺口：各端把“请求已发送”“播放器已创建”“首帧已渲染”混在同一个用户状态中；超时或播放器错误没有稳定的结构化失败码，导致用户看到卡死、黑屏或空白。
  • 不能确认的推断：不能把 6 条反馈全部归因为同一客户端 bug；HarmonyOS 的 4 条没有日志，可能分别来自设备录像为空、设备离线、服务端时间轴异常、播放组件失败或真实卡顿。
  • 一句话根因：远程视频链路缺少从请求、连接到首帧的统一状态机与超时门禁，Android 已出现“无首帧仍显示播放中”的直接缺陷，HarmonyOS 则缺失离线态赋值和错误码透传，导致多点故障看起来相同但无法合并为同一根因。

6. 建议下一步

  • 分配给：欧阳荣（Android 预览与首帧监控）、李国涛（HarmonyOS 回放状态）、陈宝旺（AddWatchEx 与跨端播放回调）。
  • Android 先修用户可见假状态：在 onRecvFirstFrame 前显示“正在连接／等待画面”，10 秒超时后进入独立失败态，保留重试入口，不再固定显示“视频播放中”。
  • 将 10 秒求流限制为有限次数，并记录每次 devId + requestId + addWatch ret + P2P 状态 + firstFrame elapsedMs；禁止在无首帧时持续叠加同一通道的开流请求。
  • HarmonyOS 补齐 ReplayPage.isOffline 的赋值链路，并让 ts_AddWatchEx 返回结构化错误；KMPCloudPlaybackVideoView 的 onError 必须把原始错误码传到页面。
  • 回归矩阵：Android 8.4.1.6 与 8.3.14.2、HarmonyOS 1.1.1.11 与 1.1.2.3，各覆盖在线设备、设备离线、无录像、录像为空、首帧超时、播放中断、重试恢复七种场景。
  • 任务账本：沿用 T-20260923-170444-60dc、T-20260926-170258-2226，状态保持 P1 / captured。

🟠 问题 2：iOS 8.1.2.4 微信登录授权码重复提交触发 30100225

1. 现象与覆盖范围

  • 257948：iOS 8.1.2.4、iPhone 26.6.2、山东青岛，21:14 提交“登录失败(30100225)”。
  • 257989：iOS 8.1.2.4、iPhone 14.7.1、上海松江，07:14 提交“登录失败(30100225)”。
  • 两条反馈来自 2 个账号、2 个机型、2 个省级地区，时间相隔约 10 小时，说明不是单一用户瞬时误操作；窗口内另有 257899 的 30100222，但该错误码在上一期已做根因分析，本期只记为重复线索，不重复计分。
  • 严重度评分：80 / 100。
  • 反馈量 10：同一错误码 2 条。
  • 共性广度 30：覆盖 2 个机型、2 个地区、同平台版本，满足 3 个维度。
  • 业务关键度 40：登录是设备、回放、消息等全部主链路的入口。

2. 神策证据

  • 反馈平台版本 8.1.2.4 对应神策 $app_version=8.1.204。
  • 2026-10-10 至 10-18，该构建的登录事件分别为 137、162、135、114、177、192、122、189、38 次，合计 1,266 次。
  • 同期 30100225 分别为 2、11、4、7、3、16、2、7、3 次，合计 55 次，占登录事件 4.34%。
  • 同期 30100222 合计 24 次，占 1.90%。两类第三方授权错误合计占 6.24%，说明旧构建上的授权失败是持续存在的长尾，而不是本窗口新出现的单点。
  • 10 月 18 日至查询时刻，该构建登录 38 次，其中 30100225 3 次、30100222 1 次，合计失败 4 次，占 10.53%。
  • 最新 iOS 8.4.106 同日也有少量 30100225，说明服务端授权失败并非只发生在 8.1.2.4；但本窗口两条明确反馈都命中了 8.1.2.4，仍需优先修客户端重复提交和恢复路径。

3. Logan 关键日志

  • 反馈 257948：
  • Log1.txt:54741-54746：请求携带非空 third_party_code=091J...，服务端返回 code=30100225, msg=授权码校验失败。
  • Log1.txt:54966-54971：约 15 秒后再次提交完全相同的授权码，服务端再次返回 30100225。
  • 两次 HTTP 请求均已完成并得到业务响应，因此不是本地网络超时；失败发生在服务端校验授权码。
  • 反馈 257989：
  • Log0.txt:625-632：请求携带非空 third_party_code=091v...，服务端返回 30100225。
  • Log0.txt:727-735：换到新的进程后再次提交同一授权码，服务端仍返回 30100225。
  • 两次尝试之间还出现一次空 code 请求并触发 30100222，说明旧授权状态没有在失败后被一致清理。

4. 代码定位

  • STLoginViewController.m:1125-1130：微信成功回调直接调用 loginRequestWithAuthCode:response.code，没有请求 ID、回调幂等或单飞判断。
  • STLoginViewController.m:1438-1463：每次微信授权使用固定 state = @"xxx"，无法区分重复回跳、旧回跳或另一次授权请求。
  • STLoginViewController.m:777-880：授权码通过 kEmptyStr(authCode) 直接进入请求体；通用空值兜底会把缺失值转换为空串，而不是在提交前终止。
  • STLoginViewController.m:889-907：失败分支没有识别 STRequestLoginVerfityFail，仅落进通用错误提示；没有清理 self.authCode，也没有自动重新拉起授权。
  • STLoginViewController.m:655-665：滑动验证完成后会再次使用 self.authCode 请求，存在复用已消费授权码的风险。
  • STRequestManager.m:175-190：老版本恢复登录路径直接从持久化状态取 loginCode 再提交微信登录，没有“一次性消费标记”。

5. 根因结论

  • 置信度：🟡 中。
  • 一句话根因：微信回调与恢复登录没有一次性 state、幂等锁和授权码消费机制，重复回跳或重试会把同一个单次授权码再次发给服务端，服务端以 30100225 拒绝后客户端仍保留旧状态。
  • 关键证据链：两份 Logan 均证明 code 非空；同一用户在同一失败时段重复提交完全相同的 code；服务端两次均返回“授权码校验失败”；代码侧确认固定 state、无单飞门禁、无 30100225 专用恢复路径。
  • 证据边界：服务端只返回“授权码校验失败”，没有区分 code 过期、已消费、应用配置错误或微信侧状态异常；不能把全部 30100225 都归因于客户端重复提交，但本窗口两例的重复 code 特征明确。

6. 建议下一步

  • 分配给：位冬（iOS 微信授权与登录回调），欧阳荣复核登录恢复路径。
  • 为每次授权生成随机、一次性 state；在 managerDidRecvAuthResponse: 校验 state、errCode、code 非空，并用请求 ID 做幂等和单飞去重。
  • 授权码一经提交即从当前会话和恢复缓存中消费；遇到 30100225 时不得复用旧 code，应清理授权态并提示用户重新发起微信授权。
  • 把 30100222、30100225 分别映射为“授权未完成”和“授权已失效”，隐藏原始错误码，保留“重新授权”和“其他登录方式”两个明确出口。
  • 回归覆盖热启动回跳、冷启动 Universal Link、重复回调、同一 code 双击提交、进程重启后恢复、code 为空、code 已消费、正常登录八种场景。
  • 任务账本：T-20261018-090804-7ee8，状态 P1 / captured。

补充数据与全量扫描

其他信号与排除项

  • AI 人形／动物侦测与报警：257957、257979 报告误报，257986 报告动物未被识别，257998 报告人形识别不准且漏录。四条覆盖 Android 与 HarmonyOS、3 个版本、4 个地区，达到进一步核查阈值，但“算法漏报”“算法误报”“报警列表拉取超时”不是同一症状。257998 的 Logan 在 07:43:31 明确出现 req_pull_device_alarm_list超时了、queryAlarmMessages failed 和空缓存回退，因此报警页面无数据至少有一层服务端请求失败；其余三条没有可比的完整日志。新建任务 T-20261018-090818-00a1，先拆分为设备侧算法、服务端报警生成、客户端列表加载三条证据链。
  • 设备离线或连接不可达：257900、257904、257944、257959、257984 共 5 条。涉及新增离线设备、设备显示离线、通电仍离线和“没连接上”，缺少可确认的设备 ID 与心跳数据，不并入远程视频簇，避免把设备在线状态问题混同为播放器问题。
  • 云存、套餐或监控中断：257936“云盘经常不能存储”、257965“充值68看不了”、257966“监控中断，宽带正常”共 3 条。分别涉及云存写入、服务权益和连接中断，当前证据不足以确认共同根因。
  • 登录其他线：257886“怎么登不上去了”为 Android 8.4.1.6 单条且无错误码，保留日志待复核；257899 的 30100222 与上一期问题同域，按 24 小时去重。
  • 功能诉求与咨询：257897 镜头遮蔽适配、257919 重置密码、257925 红外夜视、257926 画面噪音、257932 流量卡复用、257943 换手机连接设备，共 6 条，归为咨询、配置或产品诉求。
  • 无效、重复或语境不足：257913、257914、257915 为同一机型连续“好”；257923“222”、257934“去”、257949 乱码、257988 乱码；257937“什么都没有”、257967“信息不畅”无法判断具体页面，共 9 条，未进入根因分析。

本期扫描全量

关键词簇 / 分类反馈数分类处置
-102 多语言网络提示73🟣 普遍网络已排除；无具体业务链路
-101 多语言网络提示4🟣 普遍网络已排除；无具体业务链路
iOS 30100225（257948、257989）2🟠 进雷达详见问题 2
iOS 30100222（257899）1🟡 24 小时重复上一期已分析，不在本期重复展开
Android“怎么登不上去了”（257886）1🟡 单点待补证无错误码，保留 Logan 待复核
视频或回放卡死、打不开、无回放（257896、257917、257945、257947、257987、257991）6🔴 进雷达详见问题 1
云存写入、套餐后不可看、监控中断（257936、257965、257966）3🟡 待拆分分别核查云存、权益和连接链路
设备离线或未连接（257900、257904、257944、257959、257984）5🟡 已有观察线需设备 ID、在线态和心跳证据
AI 人形／动物侦测及报警（257957、257979、257986、257998）4🟠 附加核查任务 T-20261018-090818-00a1
功能诉求与咨询（257897、257919、257925、257926、257932、257943）6🟢 咨询／产品建议不进入故障根因分析
无效、重复或语境不足（257913、257914、257915、257923、257934、257949、257937、257967、257988）9🟢 无效／待澄清不进入故障根因分析
合计114进雷达 8 条 + 排除 106 条

心愿单亮点

心愿单 ID平台 / 版本诉求价值判断
5368Android / 8.4.1.6在线升级像素⭐⭐ 设备能力相关，需确认固件与芯片支持范围
5369Android / 8.3.13.3电池存电太少⭐ 更像设备硬件或功耗反馈，需转设备团队判断
5367Android / 8.4.1.6是否有电脑软件⭐ 跨端渠道咨询，可沉淀统一产品说明
5366Android / 8.3.14.2如何查找某人的所有视频录像⭐ 可通过现有筛选或检索教学解决，暂不视为新能力

数据源状态汇总

  • 反馈平台：✅ 正常。接口返回 total=114 / fetched=114 / complete=true；日期参数未在服务端生效，报告按 createTime 二次过滤到本期窗口。
  • 心愿单：✅ 正常，4 条，complete=true。
  • 神策登录：✅ 正常，已核对 iOS 8.1.204 的 9 天登录量、30100222 与 30100225。
  • 神策出图：✅ 正常，已核对平台级、当前版本级与近 7 天失败率。
  • 神策回放：⚠️ 部分可用，有 DeviceVideoPlayback 成功／失败量，但未返回可用 fail_reason 明细。
  • Logan：⚠️ 部分覆盖。问题 1 为 2/6，问题 2 为 2/2；4 条 HarmonyOS 视频反馈和 2 条 HarmonyOS AI 反馈均未提供。
  • 代码仓：✅ 正常，iOS、Android、HarmonyOS 均已定位到具体文件与状态分支。
  • 友盟：⏭️ 未调用，本期无崩溃、ANR、闪退类反馈。
  • TAPD：⏭️ 未调用，功能性根因分析阶段不引入历史 Bug 干扰。

待补证

  1. 补采 257896、257917、257945、257987 的 HarmonyOS 日志，确认各自是设备离线、无录像、连接超时还是播放组件失败。
  2. 为 Android 无首帧场景补充 requestId、devId、AddWatch 结果、P2P 连接态、首帧耗时和超时次数，验证 10 秒求流循环是否造成重复开流。
  3. 回查 257948、257989 的微信回调次数与 state，确认同一授权码重复提交来自重复 URL 回调、页面重试还是持久化恢复。
  4. 对 257998 的 req_pull_device_alarm_list 超时做服务端请求追踪，核对同时段算法事件是否已生成但消息列表未返回。
  5. 观察 10 月 18 日完整自然日的 DeviceVideoPlayback 失败率，确认当前部分日的 5.16%～5.19% 是否持续。

下一期 = 第240期 = 2026-10-18-H17.md（今天下午 17:00；窗口 2026-10-18 09:00 ~ 17:00）

🗂️历史期次

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

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