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

🔴 问题 1：iOS 回放「当前同时播放人数已达上限」误触发——NVR 主设备与通道共享 cloudId 导致额度自占（详细分析） ｜ 负责人：欧阳荣、谭伟、位冬

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户观看录像回放时反复弹出「当前同时播放人数已达上限，请稍候重试」，随后回放界面停留在该提示态，时间轴与功能按钮全部不可用，用户原话「观看录像回放时总提示（当前观看人数已达上限）然后录像回放就看不了啦」。
• 涉及反馈：本窗口 1 条（反馈 257022，iOS，App 8.3.14.3，iPhone 26.6，辽宁葫芦岛）。

• 覆盖范围：iOS 单平台，App 8.3.14.3（注意：非当前在产主线 8.4.1.6，属较老的版本线），单机型、单用户；目标设备为大华制 9270779（devType:201、devChannelCount:8、devChannelStates:"11111111"，即 8 通道 NVR，8 路全部在线）。
• 覆盖范围的重要限制：本窗口仅此 1 条该类反馈，不能据此判定该问题在 iOS 上的普遍存在；但代码侧可证明该文案的触发条件存在结构性缺陷（见第 3、4 节），属「机制已坐实、影响面待量化」的形态。
• 严重度评分：64/100（反馈量 10 / 共性 22 / 关键度 30）——
• 反馈量与增长（10/30）：本窗口同关键词仅 1 条，无同义词聚集；
• 共性广度（22/30）：跨 1 平台 × 1 版本线 × 1 机型，但代码路径可覆盖全部 NVR / 多通道设备形态（isMultiCHIPC 与 isNvr 共用同一 cloudId 分组键），按「机制影响面 > 样本影响面」折算取 22；
• 业务关键度（30/40）：录像回放属核心能力，按「录像回放 / 报警 = 30」取值；
• 上调依据：本期首次把该用户可见文案（replay_limmit_tips）与具体代码锚点、具体协议返回码（-7 / -14） 完整串成一条可复核的证据链，证据等级由「无」升「中」，故在基础分上上调。

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

• 关键局限（必须先说明）：本期未取得该问题可用的神策聚合口径——
• 上一期（第 229 期）query_segmentation_report 以 AppStart 为指标返回 SA-D-32-19：事件名 AppStart 不存在或失效，事件名确认连续 2 期未完成；
• 回放并发上限的判定发生在 NVR 设备侧的 NVR_REPLAY_MESSAGE 协议响应中（返回码 -7 / -14），在客户端埋点体系里没有对应的「回放被拒」事件，因此神策无法直接证明该现象。
• 因此本期证据链以 Logan + 代码反证 为主，不作跨用户覆盖面推断。
• 反向推论（重要）：反馈 257022 的 Logan 中，设备 9270779 全程 devIsOnline:1，p2pLastHeartTime 在采集期内持续前移（11:42:55 → 12:03:16，前移 20 分 21 秒），说明设备侧 P2P 心跳链路健康、在线状态稳定——排除「设备离线导致回放失败」这一路径，问题指向客户端 / 服务端的并发额度判定而非链路可用性。
• 设备心跳复算（可直接验证）：

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

• 反馈 ID：257022（iOS，App 8.3.14.3，账号 13500457272 / userId 8158752，目标设备 devId=9270779，8 通道 NVR）
• 日志体量：30,749 bytes / 4,179 行，时间跨度 11:51:42.293 ~ 12:36:48.820（约 45 分钟）。
• 关键时序（登录与设备上下文，可复算）：

11:51:43.500  初始化SDK日志信息 - os: ios, lang: zh_CN, brand: iphone, type: 26.6,
              name: seetong, version: 8.3.14.3, clientId: 70725D90-49C7-4E09-BF7A-26330BE1553E
11:51:43.610  缓存中上一次的登录账号: 8158752 - 登录类型: 2
11:51:43.961  [TPS_MSG_NEW_USER_TOKEN 8272] - access_token / refresh_token 正常下发
11:51:43.x    设备列表返回 1 台设备，devType=201（NVR），devChannelCount=8，devIsOnline=1
12:36:48.820  （日志结束，长连接保持正常，无重连、无 code:1001 断连）

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

• 必须并列记录的反向证据（抑制过度归因）：该 Logan 不覆盖用户实际点击回放的时段——日志内不存在任何回放页（STPlaybackVC）或协议报文记录，全部 HTTP 路径集中在 device/list、user/info、common/config、广告位、未读计数、升级检查等启动期接口。因此本期无法用 Logan 现场直证「-7 / -14 被返回」，只能证明「设备与链路健康 + 该用户确实在 8 通道 NVR 场景下发起回放」。
• 代码侧静态证据（本期据此给出可检验结论，机制完整闭合）：

• 协议返回码语义（对研发）：result == -7 与 result == -14 是 NVR 侧 NVR_REPLAY_MESSAGE 的回放路数 / 并发已满应答。源码注释记录了该判定的历史演进：STPlaybackVC.m:1417「在向 NVR 请求回放时，返回值为 -8 时向用户提示"预览人数已满"。TS8108d 等系列产品同时响应的回放路数有一定限制」，STPlaybackVC.m:1419「之前是判断 -8，现在改成 8218 是 -7；8227 是 -14」——说明该文案先天就是为「NVR 并发额度用尽」设计的，只有在额度真的被别的会话占用时才应出现。

4. 代码定位（详细）

• 涉及模块：Seetong-App-iOS（Seetong_tps）录像回放链路 + 设备分组模型
• 关键类与位置：
• STPlaybackVC.m:1416-1432（nvrPlaybackPlayFailBlock 装配与 -7 / -14 判定）
• STPlaybackVC.m:1497-1510（updateLimitUIWithLimit:，文案与 UI 降级）
• STPlaybackVC.m:3555、3621、4829（读取 hintLabel.text 判断是否处于上限态，进而禁用批量下载等能力）
• STPlaybackVC.m:5082、5663（updateLimitUIWithLimit:NO，清除上限态）
• STPlaybackVC.m:5478-5482（按 cloudId 取设备数组）、6046-6048 / 6501（camera_nvr = cameraArray.firstObject）
• STDeviceListModel.m:645-657（cloudId 与 uid 的构造规则）
• DeviceListModel.m:56-96（devGroupDict 按 cloudId 分组）
• STDeviceListService.m:194-205（getDevicesWithCloudId: 按分组取数组，返回不可变副本）
• Camera.h:500（cloudId 声明与「不带 -CH-」语义）
• 调用链（可复算）：

回放页进入 → STPlaybackVC.setupUI → camera_nvr = cameraArray.firstObject（:6046）→ 请求回放 → NVR 返回 -7 / -14 → TSCameraBlock.nvrPlaybackPlayFailBlock（:1416）→ updateLimitUIWithLimit:YES（:1422）→ stopAndResetPlayback + hiddenFunctionView + hintLabel.text = replay_limmit_tips（:1504）→ 用户看到「当前同时播放人数已达上限」且回放不可用

• 关键分支（本期认定的结构性缺陷所在）：cloudId 是 NVR 主设备与它全部通道的公共键（Camera.h:500 注释「不带 -CH-」、STDeviceListModel.m:657 赋值）。因此 getDevicesWithCloudId: 返回的数组同时包含主设备与 8 个通道；而回放上下文取 firstObject，在切换通道 / 重新进入回放时会在「主设备」与「通道」之间来回绑定。若 NVR 侧把「主设备会话」与「通道会话」计为不同并发，则客户端在单用户单设备场景下就可能把自己的额度占满 → 返回 -7 / -14 → 弹出「人数已达上限」。
• 修复方向锚点（按优先级）：

1. 统一会话归属：在 STPlaybackVC.m:6046-6048 / 6501 取 cameraArray.firstObject 时，明确只取本次回放的目标通道（按 uid 含 -CH-n 匹配），避免主设备与通道交替占据回放会话；
2. 回调去误报：STPlaybackVC.m:1416-1432 的 -7 / -14 分支在 updateLimitUIWithLimit:YES 之前，应先核对本地是否只有一个活跃回放会话（如 recPlayBlock 无其他活跃 devId）；若无其他会话，则应按「设备侧额度瞬时竞态」处理为自动重试而非直接判「人数已满」；
3. 文案分层：replay_limmit_tips（Localizable.strings:1744）目前同时承担「设备并发满」「NVR 路数满」「瞬时竞态」三种语义，建议区分文案，避免把可自愈的竞态直接呈现为不可用；
4. updateLimitUIWithLimit:YES 内的 stopAndResetPlayback 属破坏性降级，建议改为「保留时间轴 + 顶部提示 + 自动重试」，避免单次误判把整个回放体验打断。

5. 根因结论

• 置信度：🟡 中（代码链与文案完全闭合，且 cloudId 共享规则可静态复算；但缺该用户实际点击回放时段的 Logan，无法直接观测 -7 / -14 返回，故不上探到「强」）
• 一句话根因：iOS 端 cloudId 被定义为「NVR 主设备与全部通道的公共分组键」（Camera.h:500 / STDeviceListModel.m:657），回放页又固定以 cameraArray.firstObject 作为回放上下文（STPlaybackVC.m:6046-6048），使单用户单设备场景下也可能同时占用「主设备会话」与「通道会话」两份 NVR 并发额度；一旦 NVR 返回 -7 / -14，STPlaybackVC.m:1422 立即把它翻译成「当前同时播放人数已达上限」并强制停止回放、隐藏功能栏，用户表现为「回放看不了」。
• 关键证据链：用户原话 × Localizable.strings:1744 文案逐字命中 × STPlaybackVC.m:1504 文案使用点 × STPlaybackVC.m:1416-1422 的 -7 / -14 判定 × Camera.h:500 + STDeviceListModel.m:657 的 cloudId 共享规则 × DeviceListModel.m:57 按 cloudId 分组 × STPlaybackVC.m:6046 取 firstObject；并叠加 Logan 反证「设备在线、心跳持续前移、长连接零断连」，把链路可用性因素排除。

6. 建议下一步

• 分配给：iOS 回放链路 owner（主）+ NVR / 服务端并发额度 owner（辅）
• 优先处理项：

1. 复现：iPhone + iOS 8.3.14.3（与 8.4.1.6 各一轮），单账号单 8 通道 NVR，连续切换 CH-1 ~ CH-4 发起回放各 10 次，统计 replay_limmit_tips 弹出率；重点验证是否在无第二个观看者时也能复现；
2. 额度归属核对：向服务端确认「NVR 主设备会话」与「通道会话」是否分别计数；若分别计数，则确认客户端切通道时是否释放上一路会话（对应 STPlaybackVC.m:6046 的 firstObject 绑定逻辑）；
3. 文案与降级策略：按修复方向 2、3、4 拆分为「自动重试 + 区分文案 + 非破坏性提示」。

• 验证方法：修复候选包中，单账号单 NVR 连续 10 次切通道回放，replay_limmit_tips 弹出率 0%；且设备侧并发计数在任一时刻≤ 1。
• 任务账本：新增 T-20261013-170000-e5f6（见文末）。

🟠 问题 2：Android 设备列表离线态与心跳时序自相矛盾——lastHeartTime 滞后 12h44m 而客户端仍在 P2P 建链（详细分析） ｜ 负责人：张威、唐胜

1. 现象与覆盖范围

• 现象描述（已脱敏）：用户反馈设备「频繁离线」，即设备在设备列表中出现离线标识并反复出现；同时用户强调本地网络无异常。
• 涉及反馈：本窗口 1 条深度归因（反馈 257029，Android，App 8.4.1.6，HUAWEI PPA-AL20，山西忻州保德县）；同窗口另有 257031 / 257032（同账号 17604214792 提交两条，辽宁沈阳）、257030（iOS，「总断网，断断续续的」）、256997 / 257026 / 257040（HarmonyOS 离线类，零 Logan），一并作为形态旁证记录，本期只对 257029 做深度归因。

• 覆盖范围：Android 单平台，App 8.4.1.6，机型 HUAWEI PPA-AL20，单设备（devId=17751209，2 通道 IPC，devType:101）；旁证 257031 / 257032 为同一用户同一设备（devId=25853865，2 通道 IPC），257030 为 iOS 同形态。
• 严重度评分：60/100（反馈量 20 / 共性 20 / 关键度 20→30 折算后取 20）——
• 反馈量与增长（20/30）：本窗口离线 / 掉线 / 连不上族共 6 条（含 HarmonyOS 3 条零 Logan），跨 3 平台，但独立用户数少且无同关键词聚集，取 3-5 条档；
• 共性广度（20/30）：跨 Android / iOS / HarmonyOS 三平台、多机型、多地区（山西 / 辽宁 / 黑龙江 / 河北 / 陕西），≥3 维量级；因各平台证据强度不一，未给满分；
• 业务关键度（30/40）：设备离线直接影响监控可用性，按「设备掉线 / 远程查看 = 40」档下调取值（本期根因未定，不上探满分）。
• 必须说明的定性边界：本期不能把 6 条离线类反馈合并判定为「同一根因」。257029 的 Logan 给出的是一条客户端状态一致性线索；257031 / 257032 的 Logan 显示设备全程在线、且伴随真实网络断开回调（见第 3 节）；HarmonyOS 3 条无 Logan。三条子路径根因不同，本期只对 257029 做归因。

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

• 关键局限（必须先说明）：本期未取得该问题可用的神策聚合口径——事件名确认连续 2 期未完成（第 229 期 query_segmentation_report 以 AppStart 为指标返回 SA-D-32-19，本期按 skill 规则未重试，直接降级）。
• 因此本期证据链以 Logan 时序 + 心跳时间戳复算 为主，不作跨用户覆盖面推断。
• 反向推论（重要）：三份 Logan（257029 / 257031 / 257032）中的设备列表接口均返回 HTTP 200 且结构完整，/seetong-member-device/device/list 无错误码、无超时——说明服务端接口层正常，问题不在设备列表接口本身，而在「客户端如何解读与呈现 devIsOnline / 心跳字段」。
• 心跳字段复算（可直接验证）：

→ 关键对比：257022 的 p2pLastHeartTime 在 45 分钟采集期内前移了 20 分 21 秒（在线标杆），而 257029 的对应字段停留在 12 小时前。这是本期最硬的一条量化证据。

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

• 反馈 ID：257029（Android，App 8.4.1.6，设备 devId=17751209，SN 0A19519EC4CB30D1，2 通道 IPC）
• 日志体量：100,738 bytes / 4,070 行，时间跨度 06:09:50 ~ 06:09:58（约 8 秒，冷启动窗口）。
• 关键证据（设备被判定离线，可直接复算）：

06:09:52.308  SeetongLog-setDeviceListToSDK->content cache:
              [{"devName":"院子里","devId":17751209,"devSn":"0A19519EC4CB30D1",
                "devIsOnline":0,"devChannelCount":2,"devChannelStates":"11",
                "lastHeartTime":1791797107000,"p2pLastHeartTime":1791800352000,
                "p2pServer":"14.103.135.96:10018","devType":101,"devSubType":1}]
06:09:53.045  {"code":200,...,"devIsOnline":0,...,"requestUrl:/seetong-member-device/device/list}
06:09:53.309  LibImpl-doMsgRspCB devId=17751209 TPS_MSG_P2P_OFFLINE dev4gOnline=-1   ← 客户端确认离线
06:09:56.100  SeetongLog-setDeviceListToSDK->content: [{"devId":17751209,"devIsOnline":0, ...}]  ← 二次确认

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

• 对比组（257031 / 257032，同形态但不成立）：
• 设备 25853865 在两份 Logan 中全程 devIsOnline:1，且 p2pLastHeartTime 距采集时刻仅 7 分 20 秒（健康）；
• 但 257032 的 Logan 中出现了真实的网络断开回调：

08:05:39.918  [ConnectivityThread] NetworkCallbackManager-网络断开连接
08:05:39.94x  [ConnectivityThread] NetworkCallbackManager-网络改变：false
08:08:28.948  PreviewPlayerView-startPlay        ← 网络恢复后用户进入监控
08:08:30.6xx  LibImpl-addWatch ... add_watch_result=-1
08:08:31.254  PreviewPlayerView-onRecvFirstFrame: 25853865   ← 首帧 2.3 秒，正常

→ 用户所述「离线 / 连不上」在 257031 / 257032 上由手机侧真实断网解释（NetworkCallbackManager-网络断开连接），归入排除项，不与 257029 合并归因。

• 旁证（257030，iOS）：采集期 15:22:32 ~ 15:26:14，长连接 15:22:35.473 长连接连接成功 - 耗时: 0.5 秒，全程无断连、无重连；设备 devIsOnline:1。该条「总断网，断断续续的」在 Logan 中无对应证据（窗口仅 3 分 42 秒的冷启动，不覆盖用户所述时段），标为待补证。

4. 代码定位（详细）

• 涉及模块：Seetong-App-Android（Kotlin / Kuikly 层）设备列表与 SDK 状态同步
• 关键类（由 Logan 类名反推，本期未完成行号级锚定）：
• LibImpl（doMsgRspCB → TPS_MSG_P2P_OFFLINE、addWatch / onRecvFirstFrame、onP2PNetType）
• com.seetong.app.seetong.tools.WSManager（connect / reConnectCount 日志）
• SeetongLog-setDeviceListToSDK->content / SeetongLog-TIme-setDeviceListToSDK->content cache（两路设备列表写入点，见下）
• NetworkCallbackManager（网络断开连接 / 网络改变：true|false）
• PreviewPlayerView / PlayerPreviewActivity（播放链路）
• 调用链（日志可证）：

冷启动 → device/list（HTTP 200，devIsOnline:0）→ setDeviceListToSDK 写入缓存 → LibImpl.doMsgRspCB: TPS_MSG_P2P_OFFLINE(dev4gOnline=-1) → 设备列表呈现离线

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

1. dev4gOnline=-1 的语义：无 4G 设备上该字段恒为 -1，还是「未取到」？需 Net-SDK owner 确认，是判定「无 4G 能力」还是「查询失败」；
2. 两路设备列表写入的一致性：日志同时存在 SeetongLog-r ... requestUrl:/seetong-member-device/device/list 与 SeetongLog-TIme-setDeviceListToSDK->content cache 两个写入点，在 257029 中两者一致（均离线），但需确认二者写入顺序与覆盖关系，排除「旧缓存覆盖新状态」；
3. 客户端是否有本地在线探测兜底：设备 p2pLastHeartTime 停在 11 小时前，但客户端未发起任何 P2P 连接尝试（257029 中 onP2PNetType 为零次，257031 中则有 LibImpl-onP2PNetType{...nResult=7,...}）。即服务端说离线 → 客户端直接采信并置灰，没有「尝试建链以确认」的兜底路径。

• 修复方向锚点：
• 在设备列表状态判定处引入双源校验：服务端 devIsOnline == 0 且 dev4gOnline == -1 时，不应直接置灰，宜标记为「状态未知 / 待确认」并发起一次轻量 P2P 探测；
• 对齐 lastHeartTime 与 p2pLastHeartTime 的取值优先级（本期二者相差 54 分钟，且都严重滞后），确认客户端展示用的是哪一个；
• 为「频繁离线」类反馈补首帧 / 建链结果埋点，使下期可从神策侧量化（承接第 229 期「add_watch_result=-1 语义确认」待补证项）。

5. 根因结论

• 置信度：🟡 中（心跳时间戳与客户端回调均为硬证据，可复算；但缺服务端判定逻辑与第二独立样本，且用户所述「频繁」需长时间窗口日志才能证实，故不上探到「强」）
• 一句话根因：待定（倾向客户端状态一致性缺陷）——设备 lastHeartTime 早在 12 小时 44 分前即停止更新，服务端据以返回 devIsOnline:0，客户端在 LibImpl.doMsgRspCB 收到 TPS_MSG_P2P_OFFLINE 后直接采信并置灰，全程未做任何本地 P2P 建链探测（对照 257031 有 onP2PNetType 记录）→ 一次服务端判定即固化为用户可见的「离线」。
• 关键证据链：devIsOnline:0（双路一致）× lastHeartTime 滞后 12h44m × p2pLastHeartTime 滞后 11h50m × TPS_MSG_P2P_OFFLINE dev4gOnline=-1 × 零次 onP2PNetType（无本地探测）× 对照组 257022 p2pLastHeartTime 45 分钟内前移 20 分 21 秒（证明该字段本应持续更新）。

6. 建议下一步

• 分配给：Android 设备列表 owner（主）+ Net-SDK owner（辅，确认 dev4gOnline=-1 与心跳字段语义）
• 优先处理项：

1. 确认 TPS_MSG_P2P_OFFLINE / dev4gOnline=-1 的触发语义：是「服务端广播设备已离线」还是「本地 P2P 探测失败」；若是后者，需确认客户端在收到后是否应立即重试；
2. 补本地探测兜底：服务端态为离线时，允许用户点击触发一次 P2P 探测，并在探测成功时纠正列表态；
3. 回访反馈 257029 用户（山西忻州，15934304796），确认设备当前实际 ONLINE / OFFLINE，并要求上传一次覆盖「在线时段」的全量日志——本期 Logan 仅 8 秒冷启动，不足以证实「频繁」。

• 验证方法：修复候选包中，同一账号在服务端态为离线但设备实际在线时，冷启动 10 次，列表态不再直接置灰或能通过一次点击纠正；同时确认 lastHeartTime 滞后 > 1 小时时的 UI 呈现规则。
• 任务账本：新增 T-20261013-170000-a7b8（见文末）。

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

• 本窗口 HarmonyOS 反馈 8 条（跨 6 机型、8 个地区——含海外新加坡），1.1.1.11 占 8/8（100%）。
• 主题分布：离线 / 掉线 / 连不上 3（257026 / 257040 / 256997）、回放·存储 1（256994「无法录像看回放。内存卡无法格式化」）、画质·扫码 1（257018「扫码添加二维码模糊扫不出来」）、卡顿 1（257036「我这监控老是卡，网络没问题就是卡怎么回事」）、咨询 2（256976「看不到视频怎么办？」/ 257034「手机升级到鸿蒙 6.0，工程商功能怎么没有了」）。
• 零 Logan 缺口连续第 9 期未解：本窗口 HarmonyOS 8/8 条零 Logan（对照 Android 49/58、iOS 3/5），本期无法给出任何根因判断，仅作聚集记录。
• 机型清单：TLR-AL00（2 条，内蒙古呼和浩特 / 新加坡）、ALN-AL00（2 条，辽宁沈阳 / 河北邯郸）、HBN-AL80、HBP-AL00、CHZ-AL00、MIA-AL00。
• 严重度评分：60/100（反馈量 20 / 共性 24 / 关键度 16），置信度 弱。
• 处置：沿用任务 T-20260926-170258-2226（本期为第 9 期），不重复创单。

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

本窗口共扫描 71 条反馈；其中 49 条为 -102 及多语言同源网络模板（🟣 已排除）。

下表为其余 22 条的逐条分类与处置。

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

同窗口另有心愿单 8 条（5274 ~ 5281），接口 total=5281 / fetched=1000 / complete=false（触顶），已按「至少 1000 条」口径使用。其中较有价值的诉求：

心愿单亮点（值得关注）

数据源状态汇总

协议语义记录（供后续期次复用）：

• NVR 回放并发上限协议为 NVR_REPLAY_MESSAGE，返回码 -7（8218）/ -14（8227）表示回放路数已满；历史上曾用 -8 判定（见 STPlaybackVC.m:1417、:1419 注释）。
• iOS cloudId = 不带 -CH- 的设备 ID，是「主设备 + 全部通道」的公共分组键（Camera.h:500、STDeviceListModel.m:657）。
• Android TPS_MSG_P2P_OFFLINE 携带 dev4gOnline 字段；非 4G 设备上该字段可为 -1，语义待 Net-SDK 确认。

方法学记录：本期 Logan 下载改用反馈服务内置鉴权（app-logan.seetong.com 需 Authorization: Basic），与既有 seetong_feedback_server.py 的 _download_and_parse_log 保持一致——这是「同一 URL 取不到日志」这一常见误判的正解。

任务账本

说明：问题 1（回放并发额度误判）与 T-20260926-170258-576a（回放熄屏）、T-20260923-170415-9496（卡回放拖动卡顿）分属不同模块与根因（并发额度 vs 屏幕常亮 vs 拖动性能），已按 skill 规则独立建单，未合并。问题 2（离线态呈现）与 T-20260926-115214-fdf9（HarmonyOS 设备已联网但列表显示离线）同属「列表在线态呈现」族但平台不同（Android vs HarmonyOS），同样独立建单，未合并。

待补证

• 问题 1 的实际回放时段 Logan（关键缺口）：反馈 257022 的 Logan 仅覆盖 11:51:42 ~ 12:36:48 的两次冷启动，不含用户点击回放的操作（全量检索「回放 / 播放 / Playback / 上限」零命中）。需下一期定向回访该用户（13500457272）或补采，以确认 nvrPlaybackPlayFailBlock 是否真的返回 -7 / -14，以及当时是否确有第二观看者。
• 问题 1 的并发额度归属（最高优先）：需 NVR / 服务端 owner 确认「主设备会话」与「通道会话」是否分别计入并发。若分别计数，则 STPlaybackVC.m:6046 的 cameraArray.firstObject 绑定逻辑需改为按目标通道匹配。
• 问题 1 的版本覆盖面：本期样本为 8.3.14.3（非在产主线 8.4.1.6）。需确认 8.4.1.6 上 cloudId 分组与 nvrPlaybackPlayFailBlock 判定是否已变更——若未变更，影响面比单条样本更大。
• 问题 2 的 dev4gOnline=-1 语义：需 Net-SDK owner 确认非 4G 设备上该字段是「无能力」还是「查询失败」；若是后者，客户端不应据以置灰。
• 问题 2 的「频繁」取证缺口：反馈 257029 的 Logan 仅 8 秒冷启动，无法证实「频繁」。需回访用户（15934304796，山西忻州）并索取覆盖在线时段的完整日志。
• 问题 2 的双路设备列表写入一致性：SeetongLog-r ... device/list 与 SeetongLog-TIme-setDeviceListToSDK->content cache 两个写入点的顺序与覆盖关系需确认，排除「旧缓存覆盖新状态」。
• add_watch_result=-1 语义（连续 2 期未完成，第 229 期结转）：第 229 期确认为「非最终失败」；本期新样本 256993（13 次 -1，首帧 2.3 秒） 与 257031（3 次 -1，首帧 2.3 秒） 均未复现长时滞（对照第 229 期 256963 的 105 秒）。需 Net-SDK / PlayCtrl owner 确认 -1 是「通道未就绪」还是「已在取流中」，否则无法判断应否加前置门控。
• TPS_MSG_P2P_OFFLINE 与本地探测的关系：本期 257029 收到该回调后零次 onP2PNetType，而 257031 有 onP2PNetType{...nResult=7,...}。需确认客户端在收到离线广播后是否本就应放弃探测。
• 257030（iOS，总断网，断断续续的）：Logan 窗口仅 3 分 42 秒（15:22:32 ~ 15:26:14），长连接全程正常、无断连，不覆盖用户所述时段。需下期定向补采。
• 256999（Android vivo V2359A，「操作不灵敏 + 不显示报警视频」）：Logan 窗口仅 3 秒（06:09:37 ~ 06:09:40），无任何播放或报警页记录，不足以归因；该反馈含两个独立主张（操作灵敏度、报警视频缺失），建议下期拆分处理。
• 257024（iOS iPhone 26.2.1，「卡顿」）：无 Logan，与本期播放链路形态相关但不可归因，下期若再现即进雷达。
• HarmonyOS Logan 缺口（连续 9 期阻塞根因，最高优先）：本窗口 8/8 条零 Logan（对照 Android 49/58、iOS 3/5）。建议持续固定披露该比值以量化缺口。
• 神策事件名确认（连续 2 期未完成）：需先用 list_event_schemas 确认真实的首帧时延 / 预览会话 / 回放事件名，再补 7 天趋势；本期按 skill 规则降级，未重试。

下一期 = 第231期 = 2026-10-14-H09（明天早上 9:00；窗口 今日 17:00 ~ 明早 09:00）