You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been always having this issue always lately. as mentioned in another comment, I add 't=60' to the end of the Youtube URL to bypass it. the problem though, is you have to do it every other 59s!
YouTube SABR cliff cluster — same root cause across this thread and #1050 / #1076. YouTube's player has multiple ways to push you into the SABR (low-bandwidth-mobile) streaming path even when youtube_via_relay is OFF:
UA detection (preexisting): when chunks route via SNI rewrite, the GFE pretends the SNI-host UA is what's making the request. SABR routing happens server-side based on that UA assessment.
Server-side experiment rotation: YouTube periodically rotates which UAs / IP ranges get the SABR path. Some users see clean weeks then sudden breakage with no client-side change.
Player JS bootstrap state: snapshotted at the initial tab load. If the bootstrap sees "restricted" or "geo'd" the player config caches that across navigations until full reload.
What's actually fixable from our side:
PR feat(youtube): relay_url_patterns + SABR strip + exit-node-full SNI #977 (in active community testing) strips the &sabr=1&rqh=1 query params from googlevideo.com URLs before they hit our relay. The empirical claim is that YouTube falls back to a non-SABR streaming path that has no 59s cliff. If this lands, it's the structural fix.
Verify you're on v1.9.22 (mhrv-rs --version) — Full mode users on older versions got 30s timeouts that masquerade as "videos won't play".
?t= increment trick (bandaid fix for youtube 0:59 buffering #942's Sherrybmd workaround): when video stalls at 59s, edit URL to ?t=60s, page reloads from that point, plays another ~60s. Manual but reliable.
Mid-session toggle trick (YouTube restricted mode/safe mode fix #986's Amin177a workaround): load YouTube tab with youtube_via_relay: false, then flip to true and restart mhrv-rs without closing the tab. Inherits non-restricted bootstrap state.
For the 0-bytes-served symptom specifically: usually CA install issue. Verify Settings → Security → Trusted credentials → mhrv-rs CA is listed.
Track PR #977 for the architectural fix; manual workarounds for today.
Closing this batch (#561, #1050, #1076) — please follow PR #977 + use the workarounds. Reopen if you confirm v1.9.22 is installed AND none of the workarounds help; that'd be new signal.
[reply via Anthropic Claude | reviewed by @therealaleph]
Activity
Netman82 commentedon May 11, 2026
I've been always having this issue always lately. as mentioned in another comment, I add 't=60' to the end of the Youtube URL to bypass it. the problem though, is you have to do it every other 59s!
therealaleph commentedon May 11, 2026
Reviewed via Anthropic Claude.
YouTube SABR cliff cluster — same root cause across this thread and #1050 / #1076. YouTube's player has multiple ways to push you into the SABR (low-bandwidth-mobile) streaming path even when
youtube_via_relayis OFF:What's actually fixable from our side:
&sabr=1&rqh=1query params fromgooglevideo.comURLs before they hit our relay. The empirical claim is that YouTube falls back to a non-SABR streaming path that has no 59s cliff. If this lands, it's the structural fix.What you can do today:
mhrv-rs --version) — Full mode users on older versions got 30s timeouts that masquerade as "videos won't play".?t=increment trick (bandaid fix for youtube 0:59 buffering #942's Sherrybmd workaround): when video stalls at 59s, edit URL to?t=60s, page reloads from that point, plays another ~60s. Manual but reliable.youtube_via_relay: false, then flip totrueand restart mhrv-rs without closing the tab. Inherits non-restricted bootstrap state.mhrv-rs CAis listed.Track PR #977 for the architectural fix; manual workarounds for today.
Closing this batch (#561, #1050, #1076) — please follow PR #977 + use the workarounds. Reopen if you confirm v1.9.22 is installed AND none of the workarounds help; that'd be new signal.
[reply via Anthropic Claude | reviewed by @therealaleph]