Skip to content

uxplay: don't lose a /play that arrives while the video renderer is rebuilt - #599

Open
danieldhaiti wants to merge 1 commit into
FDH2:masterfrom
danieldhaiti:fix-lost-play-restart-request
Open

danieldhaiti wants to merge 1 commit into
FDH2:masterfrom
danieldhaiti:fix-lost-play-restart-request

Conversation

@danieldhaiti

Copy link
Copy Markdown

Restart requests (url, relaunch_video, reset_loop, preserve_connections, ...) are posted from the http, mirror and main threads, but main_loop() cleared them on entry. A /play that arrived while the main thread was rebuilding the video renderer was silently dropped, and the HLS renderer was never built (seen with the YouTube app: a mirror teardown followed ~0.3 s later by /play).

Post the requests under one recursive lock and consume them only once, in take_restart_request(), after main_loop returns. main_loop picks mirror vs HLS from a new video_renderer_is_hls().

Tested: builds on Ubuntu (GStreamer 1.28, Release) with no new warnings. A scripted /play A then /play B 0.2-0.4 s later reproduces the lost request on master (1 player built) and is honored with this patch (2 built). 200 concurrent /stop requests: no crash, clean SIGTERM exit.

…ebuilt

Restart requests (url, relaunch_video, reset_loop, preserve_connections,
reset_httpd, close_window, full_video_reset) are posted from the http,
mirror and main threads, but main_loop() cleared them on entry. A /play
arriving while the main thread rebuilt the renderer was silently dropped
and the HLS renderer never built.

Post the requests under one recursive lock and consume them only once,
in take_restart_request(), after main_loop returns.
@fduncanh
fduncanh force-pushed the master branch 3 times, most recently from f0cd2c3 to 26be3d3 Compare October 22, 2026 00:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant