Replies: 3 comments
|
And for what it is worth, a convo with Claude _That's a huge log dump, but there's a clear signal in it. The video you're trying to play (vAZ5SacViMM) is stuck in an infinite loop: sabr_pump event=demand_start/demand_finish ... pumped=0 cached=false state=REQUESTING repeats hundreds of times, never once delivering actual bytes (pumped=0 every single time). The root cause sits just above that loop: SabrInitializationSegmentFetcher - sabr_init event=fetch_failed videoId=vAZ5SacViMM itag=137 errorType=SabrProtocolException error=Requested SABR segment was not returned: itag=137:init itag 137 is the 1080p video track, 140 is the audio track — both failed to get their initialization segment from YouTube. Without that init segment, there's nothing to play, so the player just keeps demanding data forever without ever receiving any. That's your "spinning forever, never loads" symptom explained precisely. Two more things worth being honest about: AntiBotException: Sign in to confirm you're not a bot is still firing constantly, even with your session connected. So the login didn't fully solve it — it's not that "login works now, login didn't work before"; both states show the same error pattern. That's a real, unresolved problem, not something I want to spin as fixed. That's the server failing to get a SABR token from your token service mid-request — a dropped connection, not an auth issue. Worth checking if that's a one-off or recurring. Given the scale of what's happening (hundreds of failed retries per video, multiple video IDs also failing metadata fetches for your recommendations feed), I don't think chasing this single video further is productive. Two useful next steps: A. Try a completely different, currently-popular video (not vAZ5SacViMM) — if it also gets stuck in the same init-segment failure loop, that confirms this is systemic (YouTube blocking your server's IP/fingerprint broadly), not specific to one video. B. Check the token service logs directly for that dropped-connection error: That confirms it plainly: "YouTube rejected the stored session." This is exactly the risk we talked about earlier, playing out in real time — the session got used once (last used 7:28 AM, same time you were testing), and YouTube flagged/invalidated it almost immediately afterward. This lines up precisely with all those AntiBotException and failed SABR init segment errors in the logs — the session was rejected server-side by YouTube, so every request using it kept failing the same way, hence the infinite retry loop. This is useful, if unwelcome, information: it's a real data point now, not just theoretical risk. A brand-new automated login got flagged within its first real usage window. At this point, honestly, I don't think reconnecting with the same account and clicking "Create a new code" is likely to hold up any better — if YouTube's detection caught it once this fast, it'll likely catch it again. A few paths forward, and I want to be upfront I can't promise any of them fixes this reliably, since none of us have visibility into YouTube's detection logic: Fall back to unauthenticated/SABR-only playback (what you had before enabling remote login) — this was already intermittently failing too, but at least wasn't actively flagged Given this is a documented, expected failure mode of the project itself, this might be worth reporting on their GitHub issues too — real evidence of how fast their remote-login sessions get flagged is useful data for them._ |
|
I am using Warp and it did solve my issue - Nice tip from a Redditor |
Uh oh!
There was an error while loading. Please reload this page.
Hi team,
I was able to log on to Youtube with a secondary account and was connected for a few mins.
I launched a video that ended up not loading
Then went back to the Youtube login screen and saw the following
Could you tell me what logs you would need to help me troubleshooting?
Thanks
All reactions