fix(playback): break output-route replan loops - #250
Conversation
|
Related server playback work: Silo-Server/silo-server#789 guards already-installed clients against false route invalidation, while Silo-Server/silo-server#790 preserves copied video for genuine Android E-AC-3 Bluetooth decoder failures. |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe audio capability manager now tracks planning-relevant route identity separately from spatializer state. Playback replans preserve fallback history for generation-only output changes and reset it when planning-relevant output capabilities change. ChangesAudio planning route handling
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This PR limits playback replanning to material output capability changes and preserves fallback history across non-material callbacks; no actionable merge-blocking risk remains beyond normal checks and review. Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
What I changed
I split Android audio output state into two concepts: full runtime state for diagnostics and a stable planning identity for deciding whether playback must be replanned. The planning identity contains the physical sink and HDR, passthrough, and channel capabilities that can change the server recipe. It excludes Spatializer state because the server does not route on that value and Media3 can change it as a consequence of remounting.
The output-route generation now advances only when that planning identity changes. I also retain attempted-plan history when an opaque context ID changes without a material route change, so a callback cannot reopen direct, remux, and transcode routes that already failed.
Why
I traced a live Android session that repeatedly cycled through direct play, remux, and transcode. The server transports were healthy. Media3 remounts triggered Spatializer callbacks, each callback was treated as a new physical output route, and the resulting replan cleared failed-route history. Loop detection therefore never got a stable history to act on.
This removes the false route change at its source. The companion server guard in Silo-Server/silo-server#789 protects already-installed builds that still send the legacy invalidation.
This change addresses route churn only. It does not claim to make an unsupported E-AC-3 Bluetooth path direct-play; the separate server fallback preserves the original video and converts only audio when Android genuinely reports a decoder failure.
Validation
Source implementation and production validation: blurbery/silo-android#4.
Related issue: N/A — narrow fix reproduced on a live deployment.
Scope and risk
A real sink, HDR, passthrough, or channel-capability change still advances route generation and replans normally. Only state that cannot affect the server playback recipe is filtered out. No API, schema, configuration, or Android TV product-surface changes are included.
AI Disclosure
Summary by CodeRabbit
Bug Fixes
Tests