When YouTube rotates player.js to a shape our six sig/nsig regex
patterns don't recognise (eg. c2f7551f, May 2026), the whole player
path used to die at extract_fns even for clients that don't need the
sig fn at all (iOS, Android, Tv all get pre-signed stream URLs).
Now sig_fn / nsig_fn extraction is best-effort. Only the signature
timestamp is required — every `needs_deobf` client needs sts in
the request payload, but the actual deobfuscation functions are only
consumed by map_url when a stream URL carries `&s=` or `&n=`.
On failure we log a warning and store an empty string; Deobfuscator
then skips the JS eval, and any deobfuscate_sig/deobfuscate_nsig
call will fail loudly with "sig fn unavailable" instead of crashing
the player.
Keeps the Tv fallback alive even when sig deobf regex breaks.
Android-only path requires Google device attestation (po_token /
botguard signing). iOS path has neither attestation nor sig deobf
requirements, so it's the cleanest "just works" default. Keep
Android in the rotation only when botguard is wired.
YouTube's Android InnerTube path returns pre-signed stream URLs (no `s=`
cipher param, no `n=` throttling param) just like the iOS path. Mark
Android as deobf-exempt and put it first in the default player client
order so the typical playback path stops fetching player.js entirely.
Avoids the `could not extract sig fn name` failure on YouTube's newer
player.js shapes (eg. c2f7551f).
Desktop stays in the rotation behind botguard for completeness; it
will still try to deobf and may fail, but it's only consulted as a
fallback for botguard-signed sessions now.
Apparently YouTube can detect randomly generated visitor data and
prevents both the iOS and TV player from being fetched
(Error: Sign in to confirm you’re not a bot). Therefore the visitor
data generation code was removed and replaced with a cache that randomly
chooses from a selection of real visitor data.
