Version of youtube-source
1.18.2 (also reproduced on 1.18.0), with lavaplayer 2.2.7, used via the v2 module (not the Lavalink plugin).
Summary
With YoutubeAudioSourceManager.DEFAULT_CLIENTS and no OAuth/poToken, every streaming client fails, so all playback throws AllClientsFailedException. IOS is the only client that can still reach playable formats, and two things in the shipped Ios client prevent it from doing so.
All of the below was re-checked immediately before filing, from two unrelated egress IPs (residential and a commercial VPN), so it is not IP reputation.
1. Ios.CLIENT_VERSION is rejected outright
Ios.CLIENT_VERSION = "19.45.4" now gets an HTTP 400 from the innertube endpoint before playability is even evaluated:
{"error":{"code":400,"message":"Precondition check failed.","status":"FAILED_PRECONDITION"}}Bumping the client version to 20.10.4 clears it.
2. Ios.getPlayerParams() breaks the IOS client
Ios overrides getPlayerParams() to return MOBILE_PLAYER_PARAMS ("CgIIAdgDAQ%3D%3D"), and NonMusicClient puts it in the payload as params. Any IOS /player request carrying that field returns:
playabilityStatus.status = ERROR
playabilityStatus.reason = "This video is unavailable"
Omitting params entirely returns OK with playable audio formats. Sending it URL-decoded (CgIIAdgDAQ== rather than CgIIAdgDAQ%3D%3D) makes no difference, so this is the field itself rather than the stray encoding — though the encoding does look unintentional for a JSON body field.
With both worked around (version 20.10.4, no params), IOS resolves and plays normally.
3. Every other default client is refused anonymously
For context on why IOS is the only remaining option — same video, same moment:
| Client |
Result |
ANDROID_VR (1.60.19, shipped) |
LOGIN_REQUIRED — "Sign in to confirm you're not a bot" |
WEB (2.20250403.01.00, shipped) |
UNPLAYABLE — "Video unavailable" |
WEB_EMBEDDED_PLAYER |
"Video player configuration error" |
TVHTML5_SIMPLY |
UNPLAYABLE — "Sign in to confirm you're not a bot" |
IOS (20.10.4, no params) |
OK, 2 playable audio formats |
ANDROID_VR was also tried at 1.61.48 and 1.62.27 with identical results, so it does not appear to be simple client-version staleness. Note that 1.18.0 → 1.18.2 ships byte-identical client versions (the version bump in that range was reverted), so upgrading does not change any of this.
Reproduction
POST https://youtubei.googleapis.com/youtubei/v1/player?prettyPrint=false
Content-Type: application/json
{"videoId":"COz9lDCFHjw",
"context":{"client":{"clientName":"IOS","clientVersion":"20.10.4","hl":"en","gl":"US"}},
"racyCheckOk":true,"contentCheckOk":true}
--> OK, 2 playable audio formats
... identical body plus "params":"CgIIAdgDAQ%3D%3D"
--> ERROR, "This video is unavailable"
... identical body with "clientVersion":"19.45.4"
--> HTTP 400, FAILED_PRECONDITION
Video IDs used: COz9lDCFHjw, Rk4QkgIFhI4, kJQP7kiw5Fk, dQw4w9WgXcQ. Same result on all four.
Unrelated, but worth recording
For a few hours on 2026-08-19 (roughly 13:30–15:30 UTC) googlevideo additionally served only ranges starting at 0 and no larger than about 1 MiB — bytes=0-1048576 returned 206 while bytes=1024000-2048000 and open-ended bytes=0- both returned 403. That made YoutubePersistentHttpStream's BUFFER_SIZE = 11862014 unusable and killed playback at the first chunk boundary even once a URL was obtained.
That has since reverted and no longer reproduces, so I am not filing it as a defect — but it may be worth knowing that the "Valid range for requesting without throttling is 0-11862014" assumption was briefly and non-obviously false, and that if it returns, the symptom is a track that plays for ~57s and then dies with a 403.
Version of youtube-source
1.18.2 (also reproduced on 1.18.0), with lavaplayer 2.2.7, used via the
v2module (not the Lavalink plugin).Summary
With
YoutubeAudioSourceManager.DEFAULT_CLIENTSand no OAuth/poToken, every streaming client fails, so all playback throwsAllClientsFailedException.IOSis the only client that can still reach playable formats, and two things in the shippedIosclient prevent it from doing so.All of the below was re-checked immediately before filing, from two unrelated egress IPs (residential and a commercial VPN), so it is not IP reputation.
1.
Ios.CLIENT_VERSIONis rejected outrightIos.CLIENT_VERSION = "19.45.4"now gets an HTTP 400 from the innertube endpoint before playability is even evaluated:{"error":{"code":400,"message":"Precondition check failed.","status":"FAILED_PRECONDITION"}}Bumping the client version to
20.10.4clears it.2.
Ios.getPlayerParams()breaks the IOS clientIosoverridesgetPlayerParams()to returnMOBILE_PLAYER_PARAMS("CgIIAdgDAQ%3D%3D"), andNonMusicClientputs it in the payload asparams. Any IOS/playerrequest carrying that field returns:Omitting
paramsentirely returnsOKwith playable audio formats. Sending it URL-decoded (CgIIAdgDAQ==rather thanCgIIAdgDAQ%3D%3D) makes no difference, so this is the field itself rather than the stray encoding — though the encoding does look unintentional for a JSON body field.With both worked around (version
20.10.4, noparams), IOS resolves and plays normally.3. Every other default client is refused anonymously
For context on why IOS is the only remaining option — same video, same moment:
ANDROID_VR(1.60.19, shipped)LOGIN_REQUIRED— "Sign in to confirm you're not a bot"WEB(2.20250403.01.00, shipped)UNPLAYABLE— "Video unavailable"WEB_EMBEDDED_PLAYERTVHTML5_SIMPLYUNPLAYABLE— "Sign in to confirm you're not a bot"IOS(20.10.4, noparams)OK, 2 playable audio formatsANDROID_VRwas also tried at1.61.48and1.62.27with identical results, so it does not appear to be simple client-version staleness. Note that 1.18.0 → 1.18.2 ships byte-identical client versions (the version bump in that range was reverted), so upgrading does not change any of this.Reproduction
Video IDs used:
COz9lDCFHjw,Rk4QkgIFhI4,kJQP7kiw5Fk,dQw4w9WgXcQ. Same result on all four.Unrelated, but worth recording
For a few hours on 2026-08-19 (roughly 13:30–15:30 UTC) googlevideo additionally served only ranges starting at 0 and no larger than about 1 MiB —
bytes=0-1048576returned 206 whilebytes=1024000-2048000and open-endedbytes=0-both returned 403. That madeYoutubePersistentHttpStream'sBUFFER_SIZE = 11862014unusable and killed playback at the first chunk boundary even once a URL was obtained.That has since reverted and no longer reproduces, so I am not filing it as a defect — but it may be worth knowing that the "Valid range for requesting without throttling is 0-11862014" assumption was briefly and non-obviously false, and that if it returns, the symptom is a track that plays for ~57s and then dies with a 403.