结论
超长音频（今天实测 17502 秒 / 494 MB）在 ASR 上传阶段稳定失败：
某一帧 ws.send 阻塞超过 SDK 的 idle_timeout=300s，抛
AsrError("timeout", "发送音频帧超过 idle_timeout")。
两个叠加问题让它必然失败、且现有重试预算完全没生效：
- VTA 从不传
idle_timeout，用的是 SDK 硬编码默认值 300s
（transcriber/capswriter_client.py 的 sdk_kwargs 只有 encoding / seg_duration /
seg_overlap / on_progress / deadline_total）。SDK 两个入口
transcribe_file / transcribe_file_sync 都接受 idle_timeout 参数（默认 300.0）。
- 该
AsrError 的 retryable 不为真，而 transcribe_file 判
should_retry = exc.retryable is True，于是配置的 capswriter.max_retries=5
一次都没用上——日志里每次都是 尝试 1/5 直接终态。
证据（生产实测，2026-10-06，n305 video-transcript-api，ASR 侧 ws://192.168.31.222:6016）
live-recorder 任务 787644a07c9348b588d4b84e60336ae8（标题「清月已经不困了」，
518 MB / 17501.67 秒 = 4 小时 51 分）。同一天两次独立提交，两次同因失败：
第一次 VTA 任务 task_369063edafc64d14a77bbdc4d23c5ec3：
11:04:17 开始转录文件: data/temp/task_task_369063.../清月已经不困了.mp4 (尝试 1/5)
11:04:17 capswriter_start attempt=1/5 media=... duration=17501.673354 deadline_total=70126.693416
11:15:25 ERROR 转录文件失败: data/temp/task_task_369063.../清月已经不困了.mp4,
code=timeout, 原因: 发送音频帧超过 idle_timeout
11:15:25 RuntimeError: 转录文件失败: ..., code=timeout, 原因: 发送音频帧超过 idle_timeout
[perf] task_369063... | transcription: 668092ms (FAILED: 转录文件失败...)
任务状态更新: task_369063... -> failed
第二次（并发已归零，单独跑）VTA 任务 task_6c1c8f5858bb465fbf04522177f4a0da：
11:52:10 capswriter_start attempt=1/5 media=... duration=17501.673354 deadline_total=70126.693416
12:02:29 ERROR 转录文件失败: ..., code=timeout, 原因: 发送音频帧超过 idle_timeout
[perf] task_6c1c8f58... | transcription: 618856ms
与并发无关：第二次是在 VTA 队列空、无其他转录任务时单独跑的，仍在上传阶段卡死。
失败耗时稳定在 10-11 分钟，与「本地准备（转码/分片） + 一次 300s idle 超时」吻合。
同一文件 2026-10-03 首次提交也是 转录文件失败（当时错误详情未落进通知文本）。
影响面与边界
同批重跑对照（live-recorder 生产库 23 个历史失败样本，2026-10-06 重提交）：
| 音频时长 |
结果 |
| 8129s / 8364s / 9225s / 9388s / 9417s / 9457s / 9613s / 9864s / 12618s / 12900s |
全部成功 |
| 17502s（4.86 小时，494 MB） |
两次均失败 |
即失败阈值落在 12900s（3.6 小时）与 17502s（4.86 小时）之间，且表现为
「同一天两次都一样」，不是偶发抖动。直播录制场景里 5 小时以上的场次并不罕见。
建议修法（供参考，落点与取舍请本仓拍板）
- 主修：
sdk_kwargs 显式传 idle_timeout，取值与 deadline_total 同阶
（例如按 duration 比例给，或至少给到分钟级），让「单帧发送超时」不再先于
「总预算」把任务打死。当前 70126s 的总预算在这条路径上根本没机会用上。
- 配套：timeout 类失败是否该进
max_retries 重试。注意重试只有在 1 落地后才有意义
（同样大小、同样服务端背压下，原样重试仍会卡在同一处）；若采纳 1，重试可作为兜底而非主修。
- 备选：调小
seg_duration 以缩短单帧发送时间，缓解 TCP 背压下的单帧阻塞。
需评估对 ASR 精度与总耗时的影响，不建议无评估直接改生产配置。
关联
结论
超长音频（今天实测 17502 秒 / 494 MB）在 ASR 上传阶段稳定失败：
某一帧
ws.send阻塞超过 SDK 的idle_timeout=300s，抛AsrError("timeout", "发送音频帧超过 idle_timeout")。两个叠加问题让它必然失败、且现有重试预算完全没生效：
idle_timeout，用的是 SDK 硬编码默认值 300s（
transcriber/capswriter_client.py的sdk_kwargs只有encoding/seg_duration/seg_overlap/on_progress/deadline_total）。SDK 两个入口transcribe_file/transcribe_file_sync都接受idle_timeout参数（默认 300.0）。AsrError的retryable不为真，而transcribe_file判should_retry = exc.retryable is True，于是配置的capswriter.max_retries=5一次都没用上——日志里每次都是
尝试 1/5直接终态。证据（生产实测，2026-10-06，n305
video-transcript-api，ASR 侧ws://192.168.31.222:6016）live-recorder 任务
787644a07c9348b588d4b84e60336ae8（标题「清月已经不困了」，518 MB / 17501.67 秒 = 4 小时 51 分）。同一天两次独立提交，两次同因失败：
第一次 VTA 任务
task_369063edafc64d14a77bbdc4d23c5ec3：第二次（并发已归零，单独跑）VTA 任务
task_6c1c8f5858bb465fbf04522177f4a0da：与并发无关：第二次是在 VTA 队列空、无其他转录任务时单独跑的，仍在上传阶段卡死。
失败耗时稳定在 10-11 分钟，与「本地准备（转码/分片） + 一次 300s idle 超时」吻合。
同一文件 2026-10-03 首次提交也是
转录文件失败（当时错误详情未落进通知文本）。影响面与边界
同批重跑对照（live-recorder 生产库 23 个历史失败样本，2026-10-06 重提交）：
即失败阈值落在 12900s（3.6 小时）与 17502s（4.86 小时）之间，且表现为
「同一天两次都一样」，不是偶发抖动。直播录制场景里 5 小时以上的场次并不罕见。
建议修法（供参考，落点与取舍请本仓拍板）
sdk_kwargs显式传idle_timeout，取值与deadline_total同阶（例如按 duration 比例给，或至少给到分钟级），让「单帧发送超时」不再先于
「总预算」把任务打死。当前 70126s 的总预算在这条路径上根本没机会用上。
max_retries重试。注意重试只有在 1 落地后才有意义（同样大小、同样服务端背压下，原样重试仍会卡在同一处）；若采纳 1，重试可作为兜底而非主修。
seg_duration以缩短单帧发送时间，缓解 TCP 背压下的单帧阻塞。需评估对 ASR 精度与总耗时的影响，不建议无评估直接改生产配置。
关联
recorder://来源的时长预算机制恒失效。本 issue 的样本duration=17501.673354 deadline_total=70126.693416说明该路径当前已能取到时长（非
duration=unknown fallback=sdk_auto），修 generic/recorder:// 下载路径不写 last_media_duration，时长预算机制对该来源恒失效（静默） #170 前请先确认线上镜像是否已含相关改动，避免按过期机制排查。
max_workers=0），同日同批排查发现。