Youtube 59s and x:09s video stop workaround

[Netman82]

As I still have this issue, thought to share this:

If you get video link and generate the embed code of it, that will be no longer an issue.
https://youtubeembedcode.github.io just paste the url and wait a few seconds, once the thumbnail appeared, click play.

@therealaleph

[therealaleph]

Reviewed via Anthropic Claude.

@Netman82 — neat workaround. Adding to the documented options for the YouTube 59s problem:

1. bandaid fix for youtube 0:59 buffering #942 (@Sherrybmd): ?t=N URL increment trick — manually add 60 to the t param when video stalls.
2. YouTube restricted mode/safe mode fix #986 (@Amin177a): mid-session toggle of youtube_via_relay — load tab with it off, then flip it on without closing the tab.
3. Youtube 59s and x:09s video stop workaround #1093 (yours, @Netman82): embed-code workaround via youtubeembedcode.github.io — generate the embed for the video URL and play through that. This works because the embedded player loads the chunks via a different routing path that doesn't hit the SABR cliff.

All three are independent angles on the same underlying problem (YouTube's SABR routing for the Apps Script UA profile). The architectural fix is PR #977 which strips the &sabr=1&rqh=1 query params from googlevideo.com URLs before relay — currently in community testing.

Keeping this open as a known-workarounds tracking thread until #977 lands, since users searching for YouTube fixes benefit from finding the embed-code option. Thanks for documenting it carefully.

[dazzling-no-more]

@Netman82 thanks for sharing the embed-code workaround — adding to the list alongside #942 and #986.

Heads up on PR #977 before users find this thread expecting it to land the 59s fix automatically — I'm the PR author so wanted to surface this:

PR #977 does NOT directly fix the 59s problem at default config. The "SABR strip" in that PR turned out to be protobuf-body stripping (mirrors upstream Python's _strip_sabr_quality_tracks), not URL-query-param stripping. Community testing on the PR showed two iterations of body-stripping break video playback — empty googlevideo responses, buffer never advances, player retries indefinitely. After @unacoder's testing data we flipped sabr_strip to default false, opt-in only. So #977 as it lands will ship the SafeSearch / /youtubei/ routing fix (upstream b3b9220) and the exit-node-full SNI override (upstream 88b2767), but the 59s stall remains unaddressed in the default install.

The three workarounds remain the answer for now:

1. bandaid fix for youtube 0:59 buffering #942 (@Sherrybmd): ?t=N URL increment trick
2. YouTube restricted mode/safe mode fix #986 (@Amin177a): mid-session toggle of youtube_via_relay
3. Youtube 59s and x:09s video stop workaround #1093 (@Netman82): embed-code workaround via youtubeembedcode.github.io

All three plausibly work for the same underlying reason: they force the player onto a non-SABR routing path, which the embed player uses by default and which the standard /watch?v= page hits only after some state reset.

Planned followup: once #977 lands on main, I'd like to take a swing at stripping the &sabr=1&rqh=1 query params directly from googlevideo URLs before relay — the approach @therealaleph's earlier review of #977 thought it described. That's a different layer than the protobuf strip we tried, and it mirrors what the embed player does at the URL level (no &sabr=1 → googlevideo returns non-SABR chunks). It's a small experiment but a plausible architectural fix; better as its own PR rather than expanding #977 further.