Claude ac2d5c9501 Fix REAL bug: HTTP timeout was truncating Radio Paradise blocks ...

ROOT CAUSE IDENTIFIED:
The previous "wait for playback duration" workaround was masking the real
issue. Radio Paradise blocks last ~20 minutes (1200s), but the HTTP timeout
was only 180 seconds, causing premature stream termination.

With backpressure from the audio pipeline, HTTP download proceeds at real-time
pace. A 20-minute block takes ~20 minutes to download. The 180s timeout
was killing the connection after 3 minutes, resulting in incomplete blocks.

Changes:
1. **Increase HTTP block_timeout: 180s → 7200s (2 hours)**
   - Allows complete download of even the longest blocks
   - Comment explains why such a long timeout is needed

2. **Increase MPSC channel sizes: 16 → 60 chunks**
   - Matches TimerNode max_lead_time (3.0s / 0.05s = 60 chunks)
   - Prevents stop-and-go backpressure pattern
   - Allows smooth buffering as intended

3. **Replace workaround with proper channel drainage**
   - Use tx.closed().await instead of sleep()
   - Guarantees all buffered chunks are processed
   - More architecturally sound solution

4. **Add comprehensive diagnostic traces**
   - Log expected vs actual block duration
   - Detect premature EOF (< 95% of expected duration)
   - Track bytes decoded and HTTP Content-Length
   - Monitor backpressure blocking with timing

This fixes the streaming completely. The block will now:
- Download for the full ~20 minutes (real-time with backpressure)
- Decode all audio data without truncation
- Process all chunks before pipeline shutdown

2025-11-12 10:32:47 +00:00

15 KiB

Raw Blame History

View Raw