v1.14.3
YouTube tracks play on the web again — they were pointed at a route with no fallback.
Reported as "web pe youtube videos play nahi hoti". The audio was being fetched straight from the sync worker, which sounded like one less hop and was in fact one less safety net.
YouTube tracks would not start
The player asked the sync worker for audio directly. Measured this morning — one video, twelve identical requests — five worked and seven came back refused, because YouTube intermittently walls that server and the worker has nothing to fall back on. A browser audio element treats a refusal as a dead source and simply never plays. Requests now go through the site's own streaming route, which retries across several client identities and, when YouTube refuses outright, plays the matching track from the main catalogue instead. Same video, same moment: the worker returned an error while the site route returned audio.
Pre-loading the next track could poison it
The app warms up the following song while the current one plays, but it did so without the title and artist. Those are exactly what the fallback needs to find a matching version, so a warm-up on a walled video failed — and could leave a failed result cached for the real play a moment later.