17 points theZilber 4 days ago 15 comments
IronWolve 4 days ago | parent
weird-eye-issue 4 days ago | parent
I think you probably have another plug-in that was blocking the headers from being sent in the first place... Or maybe some sort of browser setting
dmix 3 days ago | parent
FWIW I noticed this bug as well, I often listen to longform videos on youtube and it was very obvious something changed when you pull up half-finished videos it suddenly started skipping back when it didn't previously.
I view Google as too big of a faceless machine to bother investigating myself, but I'm happy someone did.
starcast2026 3 days ago | parent
Barbing 3 days ago | parent
Barbing 3 days ago | parent
Didn’t use “retarded” four times then? Not sure if that or using Chrome was worse, but now onto the cool stuff:
Chrome DevTools Protocol (CDP): neat!
20 seconds: that’s a while. Prefer it reduced to 0sec or instead maybe 1-3 seconds? Have noticed YouTube might replay a few seconds when switching from app to browser. Sometimes it’s too long and seems like a bug, other times it seems like they might’ve been accounting for the moment of distraction while opening the browser and closing the app. (I know this seems unlikely. Perhaps it felt inspired by iOS which now seemingly intelligently replays a second of a podcast that was interrupted by a call or something.)
PS: does the Android app make you tap like four times to switch to max quality even when you’re on WiFi and told the app years ago to use high quality? (Jerks!) …and yeah Google is doing (actually more than) a reasonably good job with many aspects of YouTube (zero downtime, instant loads).
weird-eye-issue 3 days ago | parent
Never had this problem. I'm in Thailand and whether I'm on mobile or Wi-Fi it's always at high quality
theZilber 2 days ago | parent
cush 3 days ago | parent
LoganDark 3 days ago | parent
theZilber 2 days ago | parent
LoganDark 2 days ago | parent
The article still calls the 20-second thing a "bug" when it's not.
theZilber 2 days ago | parent
- the main reason i consider it a bug is because there is a difference of behavior between reopening the tab, and clicking from the history on the video. Videos get loaded with two timestamps, one in the url and one through some information received from the server, if it was a feature, the two timestamps should have been the same. The other issue is it was not the case before that if you would load a video from YouTube history, it would only load a timestamp at the js level without having a url timestamp, the url timestamp is especially annoying because it creates problems when you reopen a video from history, watch for a while, pause, and starting watching again much later - it will send you way back to the point where you started rewatching the first time. (It is confusing so read this carefully)
The combination of switching the behavior to loading two timestamps, the two timestamps being different, and as a result of a switch I could be sent back in time for huge chucks of the video (ie 20 minutes, not seconds) just because i paused for a long time on a video i loaded from history, created a set of issues which can not be justified together.
And seeing here, there is at least one person like me, who watches long form content, had the same issue.
gblargg 38 minutes ago | parent
I can either conclude that remembering your position is a very hard technical problem, or that YouTube's code is garbage.
darepublic 25 minutes ago | parent