Problem
The embedded player's initShakaPlayer in web/public/static/js/pages/embed.js has separate Shaka error-event and load-rejection handlers. Both call this.shakaPlayer.destroy(), immediately clear the field, and initialize HLS without awaiting teardown.
If one DASH failure produces both signals, the second handler can dereference the cleared player or initialize HLS twice. Starting HLS before asynchronous Shaka teardown completes can also disrupt the new playback attachment.
Expected fix and verification
Use one guarded asynchronous fallback, capture the failed player, await its destruction, and initialize HLS only once. Add a DOM regression that emits both failure signals and delays destruction, verifying HLS starts once and only after teardown.
Gafton's review of #640 identified this as pre-existing: the watch-page equivalent is repaired in that PR, but the embed fallback needs the same treatment. No live embedded-player failure was claimed or reproduced during the production cutover.
Problem
The embedded player's
initShakaPlayerinweb/public/static/js/pages/embed.jshas separate Shaka error-event and load-rejection handlers. Both callthis.shakaPlayer.destroy(), immediately clear the field, and initialize HLS without awaiting teardown.If one DASH failure produces both signals, the second handler can dereference the cleared player or initialize HLS twice. Starting HLS before asynchronous Shaka teardown completes can also disrupt the new playback attachment.
Expected fix and verification
Use one guarded asynchronous fallback, capture the failed player, await its destruction, and initialize HLS only once. Add a DOM regression that emits both failure signals and delays destruction, verifying HLS starts once and only after teardown.
Gafton's review of #640 identified this as pre-existing: the watch-page equivalent is repaired in that PR, but the embed fallback needs the same treatment. No live embedded-player failure was claimed or reproduced during the production cutover.