fix(cast): wait for media session before issuing play()#485
Open
brycesub wants to merge 1 commit into
Open
Conversation
play_media(autoplay=True) starts playback only once the device fetches the
stream and establishes a media session. That handshake is asynchronous, but
play_cast() slept a fixed 5 seconds and then unconditionally called
media_controller.play(). When the session was not active yet, play() raised
pychromecast RequestFailed ("Failed to execute play.") and the unhandled
exception killed the whole cast.
This is a pre-existing race (the sleep+play block dates to 2024-02 and lives
on master untouched by the Wayland branch). It surfaces reliably with the new
Wayland --screencast path, whose cold start (portal grant + GStreamer/x264
init + buffering) routinely exceeds 5 seconds; faster paths usually beat the
sleep and so rarely tripped it.
Replace the blind sleep with media_controller.block_until_active(timeout=30),
which returns as soon as the session is ready. Then only play() when a session
is actually active (and skip it if autoplay is already playing), printing an
actionable warning instead of crashing if no session forms in time. The fix is
generic and helps every cast path, not just Wayland.
Add tests/test_cast_play.py covering the three handshake outcomes: no session
(must not crash), active session (must play), already playing (must not
re-issue play).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Casting intermittently crashes at startup with:
play_media(autoplay=True)only starts playback once the device has fetched the stream and established a media session. That handshake is asynchronous, butplay_cast()slept a fixed5seconds and then unconditionally calledmedia_controller.play(). When the session wasn't active yet,play()raisedRequestFailedand the unhandled exception killed the whole cast.This is a pre-existing race — the
sleep(5)+play()block dates back to 2024-02. It rarely triggered because most paths establish a session within 5 seconds, but a slow cold start (portal grant + encoder init + buffering) reliably exceeds it.Fix
Replace the blind sleep with
media_controller.block_until_active(timeout=30), which returns as soon as the session is ready. Then only callplay()when a session is actually active (and skip it entirely if autoplay is already playing), printing an actionable warning instead of crashing if no session forms in time.The fix is generic and benefits every cast path.
Tests
Adds
tests/test_cast_play.pycovering the three handshake outcomes:play()play()play()🤖 Generated with Claude Code