# Debug Session: eta-stopover-bug
- **Status**: [OPEN]
- **Issue**: 列车进站 ETA 仍然包含停站时间；终点站显示已正确，但 ETA 仍偏大。
- **Debug Server**: N/A
- **Log File**: N/A

## Reproduction Steps
1. 在发车牌和 Block Reader 都正常连接的情况下运行 `station_broadcast.lua`
2. 观察 `UPCOMING TRAINS` 的 ETA
3. 与 CRN 发车牌原始 ETA 对比

## Hypotheses & Verification
| ID | Hypothesis | Likelihood | Effort | Evidence |
|----|------------|------------|--------|----------|
| A | NBT 侧生成的 `announceKey` 仍未与 `create_target` 文本键完全匹配，导致没有走文本 ETA 覆盖 | High | Low | Rejected |
| B | `create_target` 文本里解析出的 ETA 本身就是“到发后/含停站”的字段，而不是进站前 ETA | Medium | Low | Inconclusive |
| C | 文本解析到了正确 ETA，但后来又被 NBT 计算值覆盖，或因为键规范化不一致而未命中覆盖 | Medium | Low | In Progress |
| D | 同一班车在 NBT 与文本中的目的地/车次格式仍有额外差异（空格、平台、后缀） | High | Low | Rejected |
| E | `create_target` 文本切分错位，把 ETA 数值丢掉了，只留下中文单位（在 CC 中显示为 `??`） | High | Low | Confirmed |
| F | NBT 中 `RealTimeArrival` / `RealTimeDeparture` 对当前用途语义与预期相反，取错字段后会把停站时间算进去 | High | Low | Confirmed |

## Log Evidence
- 屏幕证据：`TK:[Local]1123_HC-02 2`
- 屏幕证据：`NK:[Local]1123_HC-02 2`
- 屏幕证据：`TXT:-1 NBT:113 USE:113`
- 屏幕证据：`ETASTR:??`
- 结论：文本键已匹配成功，但 `etaStr` 仅剩单位文本，数值部分在切分时被错误丢弃。
- 后续证据：修复切分后，`TXT:60` 但 `USE` 仍保持 NBT 值，说明文本 ETA 未稳定命中最终覆盖，需统一键规范化。
- 样本证据：`LastRefreshed=122113`，`RealTimeDeparture=122228`，`RealTimeArrival=123428`，两者相差约 1200 tick（60s 停站时间）；取 `RealTimeArrival` 会天然带入停站时间。

## Verification Conclusion
- 已确认根因 1：`create_target` 文本解析错误地将第一段数字当成独立字段丢掉，导致 ETA 解析只看到中文单位。
- 新增根因 2：文本键与 NBT 键需要统一规范化（空格压缩/去首尾），否则文本 ETA 无法稳定覆盖最终值。
- 已确认根因 3：对于“进站 ETA”用途，应该取 `RealTimeArrival/RealTimeDeparture` 中更早的那个时间点，而不是固定取 `RealTimeArrival`。