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

🔴 问题 1：Android 8.4.1.6 进入监控长期「一直加载」——add_watch_result=-1 连续失败 40 次、首帧迟至 105 秒（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户进入设备监控预览页后画面长时间停留加载态，用户以「一直加载」四字提交反馈。日志显示进入页面后 105 秒才收到第一帧，随后恢复播放；期间应用与设备之间反复「请求取流 → 失败 → 停止 → 再请求」空转。
• 涉及反馈：本窗口 1 条（反馈 256963，账号 weizhenfenb，山东）；同窗口另有 256898「最近回放界面特别的卡拉进度条都卡」（vivo V2172A，无 Logan）与 256936「回放花屏 录不上」（iOS，有 Logan，未做深挖），三者同属「播放链路形态」但证据强度不同，本期只对 256963 做深度归因。
• 覆盖范围：Android 单平台，App 8.4.1.6，机型 OnePlus PLQ110，设备为大华制 10011344（9 通道枪球 NVR 形态，nvr channel permission 与 gun&ball device 均在日志确认）。

• 严重度评分：66/100（反馈量 10 / 共性 26 / 关键度 30）——
• 反馈量与增长（10/30）：本窗口同关键词仅 1 条，另 2 条为形态相近但无日志的单点；
• 共性广度（26/30）：跨 4 个通道（CH-1 ~ CH-4 全部复现同一模式）、1 个机型、1 个版本、1 名用户 = 3 维量级；因缺第二独立用户，未给满分；
• 业务关键度（30/40）：实时监控预览为设备可用性核心路径；
• 上调依据：本期首次拿到可复算的秒级时序直证（40 次 -1、105 秒首帧、35 次重试循环），证据等级由「弱」升「中」，故上调。

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

• 关键局限（必须先说明）：本期未取得该问题可用的神策聚合口径——
• query_segmentation_report 以 AppStart（唯一）为指标返回 SA-D-32-19：事件名 AppStart 不存在或失效；
• 客户端首帧时延在服务端事件中的落点需先用 list_event_schemas 确认真实事件名，本期时间预算已用尽，未完成该确认。
• 因此本期证据链以 Logan 秒级时序 为主，不作跨用户覆盖面推断。
• 反向推论（重要）：该 Logan 全程 add_watch_result=-1 共 137 次，其中首帧前 40 次、首帧后 96 次，且 07:21 ~ 07:31 全程持续出现——说明 -1 不是一次性的异常，而是该会话内取流路径的常态返回值；因此「一直加载」的直接触发条件更可能是「P2P 通道建立耗时」而非「-1 本身」。本期报告已按此修正归因（见第 7 节）。

3. Logan 关键日志（核心数据源，本期拿到秒级时序直证）

• 反馈 ID：256963（Android，App 8.4.1.6，账号 weizhenfenb / userId 4363498，设备 10011344）
• 日志体量：102,750 bytes / 7,385 行，时间跨度 07:19:17.400 ~ 07:31:27.148（约 12 分钟）。
• 关键时序（存活期完整链路）：

```
07:19:19.719 MainActivity2-EXTRA_LOGIN_SUCCEED:1
07:19:20.104 Check top activity: PlayerPreviewActivity, isTop:true
07:19:20.145 PlayerPreviewActivity-onCreate devid = 10011344-CH-1 ← 用户进入监控页
07:19:20.172 PreviewPlayerView-startPlay / playinfo startPlay: CH-1
07:19:20.174 LibImpl-addWatch,devId=10011344-CH-1,add_watch_result=-1 ← 首次取流即失败
07:19:20.174 LibImpl-addWatch pull stream type:0, ret:0
07:19:27.857 PreviewPlayerView-pauserPlay: CH-1 ┐
07:19:27.863 PreviewPlayerView-autoStartPlay ├ 空转循环第 1 轮
07:19:27.868 LibImpl-addWatch ... add_watch_result=-1 ┘
...（每 10 秒一轮；07:19:55 起 CH-1~CH-4 四路同时进入循环）
07:21:04.746 LibImpl-doMsgRspCB-->TPS_MSG_P2P_CONNECT_OK --> gun&ball device, size:9 ← 通道建立
07:21:05.481 onMsgRspAddWatch-->OpenStreamAgent, devId=CH-1, ret=0
07:21:05.633 PreviewPlayerView-onRecvFirstFrame: CH-4 ← 第一帧（距进入页面 105.46 s）
07:21:06.481 PreviewPlayerView-onRecvFirstFrame: CH-1 ← 本路第一帧（106.31 s）
07:21:07.850 PreviewPlayerView-onRecvFirstFrame: CH-3 （107.68 s）
07:21:07.861 PreviewPlayerView-onRecvFirstFrame: CH-2 （107.69 s）
```

• 量化事实（可直接复算）：

| 指标 | 数值 | 口径 |
|---|---|---|
| 进入页面 → 首帧 | 105.46 s（CH-4） / 106.31 s（CH-1） / 107.68 s（CH-3） / 107.69 s（CH-2） | PlayerPreviewView-startPlay → onRecvFirstFrame |
| 首帧前 pauserPlay 循环 | 35 次 | 07:19:20 ~ 07:21:05 |
| 首帧前 add_watch_result=-1 | 40 次 | 同窗口，全部为 -1，无其它返回值 |
| 首帧后 add_watch_result=-1 | 96 次（另有 1 次 -121） | 07:21:05 ~ 07:31，说明 -1 为常态 |
| 首帧前 LibImpl-addWatch,devId / LibImpl-stopWatch,devId | 80 / 72 | 取流与停流几乎一一配对，构成「取→停→取」抖动 |
| 空转期间主线程日志 | 1,256 行 / 32 个时间点 | 主线程持续被重试与 UI 刷新占据 |

• 旁证（同窗口同形态、无 Logan）：256898 描述「回放界面特别的卡拉进度条都卡」，与问题 1 同属播放链路，但未取得日志，本期不作归因，仅计入「待补证」。

4. 代码定位（详细）

• 涉及模块：Seetong-App-Android（Kotlin 层）→ Seetong-CliCmpt-Net-Sdk / PlayCtrl（native 层）
• 本期未能在 ~/Seetong-App-Android 完成逐行锚定（上层 PreviewPlayerView / PlayerPreviewActivity 的源码 grep 未返回可引用行号），以下为日志类名级锚点，需下一期补齐行号。
• 关键类（由 Logan 类名反推）：
• PreviewPlayerView（pauserPlay / autoStartPlay / onRecvFirstFrame / playinfo startPlay）
• PlayerPreviewActivity（onCreate / refreshActivityUI onRecvFirstFrame）
• PlayerDeviceManager（Created 1 new players / refreshPlayers / Handle normal scenario）
• LibImpl（addWatch / stopWatch / onMsgRspAddWatch / OpenStreamAgent / PlayAgent / doMsgRspCB）
• com.seetong.app.seetong.ui.utils.InfoUploadDevice（onGetDevCapacity / onGetDevAlgorithmInfo）
• 调用链（日志可证）：

PlayerPreviewActivity.onCreate → PreviewPlayerView.startPlay → LibImpl.addWatch → add_watch_result=-1 → PreviewPlayerView.pauserPlay → LibImpl.stopWatch → PreviewPlayerView.autoStartPlay →（循环 35 轮）→ LibImpl.doMsgRspCB: TPS_MSG_P2P_CONNECT_OK → onMsgRspAddWatch → OpenStreamAgent(ret=0) → PlayAgent(ret=0) → onRecvFirstFrame

• 关键分支（需研发确认）：

1. add_watch_result=-1 的语义：日志同时打印 pull stream type:0, ret:0，说明 -1 不等于「最终取流失败」，更像「通道尚未就绪 / 已在取流中」的中间态。这是本次归因的关键未解点。
2. 重试循环的驱动者：pauserPlay + autoStartPlay 每约 10 秒配对出现，且 07:19:55 起因四路同时进入而加剧；需确认是「首帧超时看门狗」还是「播放态与设备态比对后主动重启」。
3. 缺首帧超时兜底：进入页面后 105 秒内 UI 未向用户给出任何失败或降级提示（setVideoInfo msg: 视频播放中 与 showHelpButton: false 在循环中反复刷出），属体验层缺陷，与任务 T-20260926-170258-2226 提出的「补首帧超时与失败提示」为同一族问题。

• 修复方向锚点：
• 在 PreviewPlayerView 的首帧等待路径上引入单次超时（建议 10 ~ 15 s）+ 显式失败提示 + 手动重试按钮，替代当前的静默自动重试；
• 收敛 pauserPlay / autoStartPlay 循环的触发条件，避免 4 路并发时把主线程打满（空转期间 1,256 行主线程日志）；
• LibImpl.addWatch 的 -1 需要与 TPS_MSG_P2P_CONNECT_OK 建立状态耦合：P2P 未就绪时不应反复下发 addWatch。

5. 根因结论

• 置信度：🟡 中（Logan 时序可复算，但缺服务端口径与第二独立样本）
• 一句话根因：进入监控页时 P2P 通道尚未建立，客户端在 105 秒窗口内以约 10 秒为周期反复 addWatch（返回 -1）→ stopWatch 空转，且无首帧超时兜底，用户侧表现为「一直加载」。
• 关键证据链：Logan 中 add_watch_result=-1 40 次（首帧前）与 TPS_MSG_P2P_CONNECT_OK 于 07:21:04.746 出现后 0.9 秒内 onRecvFirstFrame 相继到达 —— 「P2P 就绪」与「首帧到达」在时间上强相关，是本期最硬的一条因果证据。

6. 建议下一步

• 分配给：Android 播放链路 owner（与 T-20260926-170258-2226 同责任人）
• 优先处理项：

1. 补首帧超时兜底 + 失败提示（体验层，可独立于根因先落）；
2. 对齐 add_watch_result=-1 的协议语义，确认是否需要「P2P 未就绪」前置门控。

• 验证方法：在 4 通道同开场景下，冷启动进入监控页连续 10 次，要求首帧 P95 < 10 s；addWatch 调用次数 ≤ 3 次/路；空转日志行数 < 100 行/次。
• 任务账本：新增 T-20261013-090000-a1b2（见文末）。

🟠 问题 2：iOS 对讲「常按松手只能听到最后几个字」——本地录音帧长 128 ms，短按首帧即被丢弃（详细分析）

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户按住对讲按钮说话、松手后，设备侧只能听到最后几个字，前面的内容丢失；用户原话「对讲功能不好用，常按松手只能听到最后几个字」。
• 涉及反馈：本窗口 1 条（反馈 256974，iOS，App 8.4.1.6，iPhone，江苏苏州）。

• 严重度评分：61/100（反馈量 10 / 共性 21 / 关键度 30）——
• 反馈量与增长（10/30）：本窗口 1 条，无同义词聚集；
• 共性广度（21/30）：1 平台 × 1 版本 × 1 机型（且未能从日志独立复现，见下），按 2 维量级取值；
• 业务关键度（30/40）：对讲属「对讲 / 添加设备 = 25」档，因涉及已生效功能的可用性（非新增诉求）上调至 30。
• 覆盖范围的重要限制：本期不能据此判定该问题在 iOS 8.4.1.6 上的普遍存在。原因见第 3 节。

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

• 客户端对讲埋点为 sensors_ipcTalkAction / sensors_nvrTalkAction（按钮点击）与 sensors_previewSessionSpeakTriggeredIsCall:（会话内对讲次数，写入 PreviewSession 缓存并在退出时上报，见 STPlayerViewSensors.m:653 / 963）。
• 本期未取得该口径的聚合数据（同上，神策事件名确认未完成）。因此不能给出「多少用户遇到对讲丢字」的量化结论。
• 可确认的一条：反馈 256974 的 Logan 中 PreviewSession save- 出现在 07:19:20.150（Android 样本）与 iOS 侧会话保存路径，说明该埋点确实在采集，下一期可直接查 PreviewSession 相关事件补证。

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

• 反馈 ID：256974（iOS，App 8.4.1.6，账号 15236310133 / userId 57496725）
• 日志体量：7,439 bytes / 756 行，时间跨度 08:52:30.551 ~ 08:56:17.376（约 3 分 47 秒）。
• 关键发现（必须先说）：该日志窗口内不存在任何对讲相关记录——
• 全量关键字检索 Intercom / Talk / Audio / Mic / Voice / 对讲 / 录音：命中 0 条（录 仅 2 条，均为「登录账号」等词形巧合）；
• 日志内 HTTP 路径清单（仅 16 类）全部为登录 / 设备列表 / 广告位 / 消息未读 / 升级检查，无一属于对讲或音频链路；
• 长连接时序完整可见：08:52:33.208 长连接连接成功 → 08:55:01.521 主动断开长连接 code:1001 reason:Stream end encountered（疑似用户退出 App）→ 08:56:17.376 长连接连接成功（重新进入）。
• 结论：该 Logan 采集的是用户反馈前后的前后两次冷启动，不覆盖用户实际操作对讲的时段。因此本期无法用 Logan 直证复现「只能听到最后几个字」。
• 代码侧静态证据（本期据此给出可检验假设，非结论）：iOS 对讲录音链路存在明确的帧级丢帧窗口，与用户描述的现象在机制上高度吻合——

| 环节 | 代码锚点 | 事实 |
|---|---|---|
| 采集缓冲 | AudioRecoder_Seetong.mm:190 | AudioQueueAllocateBuffer(recorderQueue, AUDIO_RECORD_BUFFER_SIZE=160)，即 160 字节 = 10 ms 一包 |
| 编码门槛 | AudioRecoder_Seetong.mm:383 | addAecData 的 while ([_processedData length] >= ENCODE_AUDIO_SIZE)，ENCODE_AUDIO_SIZE = 2048（AudioRecoder_Seetong.h:17） |
| 帧时长 | 由 intWithAudioParam 推导 | 2048 字节 ÷ (8000 Hz × 2 字节) = 128 ms |
| 松手路径 | Camera.mm:736（stopTalk）→ Camera.mm:797（stopAudioRecoder）→ AudioRecoder_Seetong.mm:303（stopRecoder） | stopRecoder 内执行 AudioQueueStop(recorderQueue, YES)（立即停止，丢弃未取出的缓冲）与 CameraAecm_Free(aecm_handle)，未做「编码并发送尾部残余 _processedData」 |
| 松手入口 | STCameraControlView.m:770（stopTalkAction）→ STCameraPlayerTalkView.m:535（doTalkButtonLongPressEndAction） | 松手立即回调 handleTalkEndActionForIPCOrNVR: → [camera stopTalk] |

→ 推论：用户松手瞬间，尚未累积到 2048 字节（128 ms）的尾段音频不会进入 encodeG711Audio，被整体丢弃。 按中文语速（约 4 ~ 5 字/秒），128 ms ≈ 半个字到 1 个字；若用户按压时间接近 UILongPressGestureRecognizer.minimumPressDuration = 0.2（STCameraControlView.m:748），则丢失比例会显著放大，与「只能听到最后几个字」的描述方向一致。

• 抑制该假设的反向证据（必须并列记录）：若为单纯的「尾部丢帧」，用户应描述为「结尾听不全」；而用户原话是「只能听到最后几个字」，字面上更接近「开头丢失」。两种表象需要下一期用真实对讲时段 Logan 区分。

4. 代码定位（详细）

• 涉及模块：Seetong-App-iOS（Seetong_tps）播放器对讲链路
• 关键类与位置：
• STCameraControlView.m:754（onLongPressForTalk:，UIGestureRecognizerStateBegan/Ended）、:778（startTalkUIAtView:）、:784（stopTalkAction）、:748（minimumPressDuration = 0.2）
• STCameraPlayerTalkView.m:521（doTalkButtonLongPressStartAction:）、:535（doTalkButtonLongPressEndAction:）、:546（setTalkWillStartBlock:）、:563（setTalkDidEndBlock:）
• STCameraTalkItemView.m:128（onLongPress: 状态机）、:286（cancelAction）
• STPlayerCameraControlVC.m:1438/1442（talkWillStartBlock / talkDidEndBlock 装配）、:1484（handleTalkStartActionForIPCOrNVR:）、:1518（handleTalkEndActionForIPCOrNVR:）
• Camera.mm:616（playTalk:）、:736（stopTalk）、:797（stopAudioRecoder）、:1889（audioRecoder:outputAudioData: → FC_InputAudioData）
• AudioRecoder_Seetong.mm:91（addRecordData:）、:303（stopRecoder）、:381（addAecData:）、:396（encodeG711Audio:）
• 调用链（松手路径）：

STCameraControlView.onLongPressForTalk(Ended) → stopTalkAction → STCameraPlayerTalkView.doTalkButtonLongPressEndAction → STPlayerCameraControlVC.handleTalkEndActionForIPCOrNVR → Camera.stopTalk → FC_StopTalk + stopAudioRecoder → AudioRecoder_Seetong.stopRecoder → AudioQueueStop(YES) + CameraAecm_Free

• 附加风险点（未在用户反馈中出现，但同一改动应一并处置）：handleTalkEndActionForIPCOrNVR: 只调用 [camera stopTalk]——没有调用 FC_Loc_StopSpeak，而 playTalk: 在 isLanMode 下走的是 FC_Loc_StartSpeak（Camera.mm:644）。若局域网模式（isAPCamera = uid 以 AP_TST / SmartLife- 开头，或 isLanDebugMode）下用户使用对讲，开启走 FC_Loc、停止走 FC_StopTalk，会留下未停止的本地对讲通道。本期无局域网对讲样本，标为待补证，不阻塞。
• 修复方向锚点：

1. AudioRecoder_Seetong.mm:303（stopRecoder）：在 AudioQueueStop 之前先刷新 _processedData 残余（不足 2048 字节时补零到整帧后 encodeG711Audio 发送），并同步刷新 _recordData 残余；
2. 或在 Camera.mm:736（stopTalk）中，先完成一次尾帧发送再置 _isPlayTalk = NO；
3. 复核 ENCODE_AUDIO_SIZE = 2048（128 ms）是否偏大；对「按住即说」的短语音，建议降至 512 字节（32 ms）量级以降低最坏丢帧；
4. handleTalkEndActionForIPCOrNVR: 补 isLanMode 分支（走 FC_Loc_StopSpeak）。

5. 根因结论

• 置信度：🟡 中（代码机制成立且锚点明确，但缺真实对讲时段 Logan，且用户描述的丢失方向与机制存在不一致）
• 一句话根因：iOS 对讲在松手时立即 AudioQueueStop(YES) 并释放 AECM，未冲刷不足一帧（128 ms）的尾部录音缓冲，形成固定量级的语音截断；具体丢失方向需下一期用真实时段 Logan 确认。
• 关键证据链：AudioRecoder_Seetong.h:17（2048）× AudioRecoder_Seetong.mm:383（门槛）× AudioRecoder_Seetong.mm:303（无尾帧冲刷）三者构成完整机制；反馈 256974 提供现象，但本期 Logan 不覆盖操作时段，故降级为「机制 + 现象吻合」而非「同一现场直证」。

6. 建议下一步

• 分配给：iOS 播放/音频链路 owner
• 优先处理项：

1. 复现：iPhone + iOS 8.4.1.6，按压 0.3 s / 0.5 s / 1 s 三档，各 10 次，设备侧录音回放判定首字/尾字丢失位置；
2. 按修复方向 1 或 2 补尾部冲刷，回归同用例；
3. 顺带修复局域网模式 stopTalk 未走 FC_Loc_StopSpeak 的配对缺陷。

• 验证方法：addAecData 在 stopRecoder 前被调用且 _packResquence 递增；设备侧收到的 G711 帧数与按压时长的理论帧数偏差 ≤ 1 帧。
• 任务账本：新增 T-20261013-090000-c3d4（见文末）。

🟡 问题 3：HarmonyOS 1.1.1.11 聚集连续第 8 期（弱线索，仅记录不单独深挖）

• 本窗口 HarmonyOS 反馈 17 条（跨 13 机型、10 个城市），1.1.1.11 占 15 条、1.1.1.6 占 2 条。
• 主题分布：离线/掉线/连不上 6（256889 / 256913 / 256915 / 256968 / 256972 / 256973）、回放不可用 1（256938）、存储卡 1（256903）、画质 1（256925）、设备管理 1（256890）、咨询与情绪 7。
• 零 Logan 缺口连续第 8 期未解：本窗口 HarmonyOS 17/17 条零 Logan（对照 Android 60/78、iOS 5/8），本期无法给出任何根因判断，仅作聚集记录。
• 严重度评分：64/100（反馈量 30 / 共性 24 / 关键度 10），置信度 弱。
• 处置：沿用任务 T-20260926-170258-2226（本期为第 8 期），不重复创单。

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

同窗口另有心愿单 9 条（5265 ~ 5273，产品建议与咨询，接口 complete=false，5273/1000），按 🟤 建议与咨询排除，不逐条列出。

数据源状态汇总

任务账本

说明：问题 1（首帧迟滞 + 缺超时兜底）与 T-20260926-170258-2226（HarmonyOS 预览/回放不可用）、T-20260926-115320-a60e（HarmonyOS 转圈无首帧）同属「缺首帧超时兜底」族，但平台与链路不同（Android KMP/PlayCtrl vs HarmonyOS），已按 skill 规则独立建单，未合并。

待补证

• 问题 1 的 add_watch_result=-1 语义（最高优先）：日志同帧打印 pull stream type:0, ret:0，说明 -1 并非最终失败。需 Net-SDK / PlayCtrl owner 确认 -1 是「通道未就绪」「重复请求」还是「已存在连接」，否则无法判断应否加前置门控。
• 问题 1 的第二独立样本：本窗口仅 1 条「一直加载」反馈。需在下一期扩大关键词（加载 / 转圈 / 黑屏 / 没画面）以确认是否为跨用户共性。
• 问题 1 的重试驱动者：pauserPlay / autoStartPlay 每约 10 秒配对的触发条件需从 Android 源码确认（本期未完成行号级锚定）。
• 问题 2 的真实时段 Logan（关键缺口）：反馈 256974 的 Logan 只覆盖反馈前后两次冷启动（08:52:30 ~ 08:56:17，含 08:55:01 长连接 code:1001 Stream end encountered 与 08:56:17 重连），不含对讲操作。需下一期定向回访该用户或补采，以确认丢失方向（开头 vs 结尾）。
• 问题 2 的 ENCODE_AUDIO_SIZE = 2048（128 ms）是否合理：需音频链路 owner 确认该帧长是否与设备侧播放缓冲匹配。
• 局域网对讲停止不配对：Camera.mm:1484 起 playTalk: 在 isLanMode 走 FC_Loc_StartSpeak，而 STPlayerCameraControlVC.m:1518 的结束路径只调 stopTalk（内部走 FC_StopTalk），未调 FC_Loc_StopSpeak；本期无局域网对讲样本，需专门用例覆盖。
• 256898（Android vivo V2172A，回放界面卡 / 进度条卡）：无 Logan，与问题 1 同属播放链路形态，本期未归因；下期若再现即进雷达。
• 256936（iOS，回放花屏 + 录不上）：有 Logan，本期未深挖；涉及「花屏」与「录不上」两个独立主张，建议下期拆分处理。
• 256876（Android，「报警只有画面，没有录像」）：有 Logan，本期未深挖。
• HarmonyOS Logan 缺口（连续 8 期阻塞根因）：本窗口 17/17 条零 Logan（对照 Android 60/78、iOS 5/8）。建议固定披露该比值以量化缺口。
• 神策事件名确认（连续 2 期未完成）：需先用 list_event_schemas 确认真实的首帧时延 / 预览会话事件名，再补 7 天趋势；本期按 skill 规则降级，未重试。

下一期 = 第230期 = 2026-10-13-H17（今天下午 17:00；本期为 09:00 正期，窗口 今日 09:00 ~ 17:00）