YouTube had a bug – I used ChatGPT to investigate | Hacker News Reader

YouTube had a bug – I used ChatGPT to investigate

blog.thezilber.com

20 pointstheZilber15 comments

I too noticed -20s, but I always felt it is a feature. I close browser and after a couple of days I continue watching same video. This -20s shift gives me a good context on what was the last sentence/frame, so I can comfortably continue watching. So this is a feature as far as I am concerned & felt Youtube has thought about people like me.

Bet you’re right. I just said 20sec is too long but maybe they do this for me and it feels just right so my perception and reality and opinion are a little out of sync.

This sounds like an intentional feature. Like how when your audio book gets interrupted by a notification it replays an extra second of audio. Personally I really like it.

This isn't a bug, it's intentional. YouTube will skip back some amount of time on purpose if it thinks you haven't been to the video in a while. Even if all you did was click away from the tab for some hours.

Skipping back twenty minutes in time is not a feature. The reason it was skipping in the first place was because it would use a stale param on videos opened from youtube history.

If the URL had a t= parameter then that is also a feature, but I agree that I don't like when such URLs accidentally overwrite the point of the video I wanted to resume from.

The article still calls the 20-second thing a "bug" when it's not.

Thank you everyone for the reads and the replies. I want to clarify a few things.

- 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.

> In the past few days, I noticed a bug I could not keep ignoring. Sometimes YouTube would randomly skip back in time during soft reloads

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.

On some channels YouTube consistently remembers my position server-side. On other channels, it reliably starts the video at the beginning if the tab gets reloaded, even if I was half way through. Often the video in thumbnails shows a red bar at the bottom, but still starts at the beginning.

I can either conclude that remembering your position is a very hard technical problem, or that YouTube's code is garbage.

I noticed some websites dont have proper refer and embedded youtube videos give a 153 errors. Had chatgpt debug the error, told me to install a header plugin and how to configure it. Fixed the problem.

How does that happen, I thought the referer header was set by the browser how do websites impact what is sent in the context of an embedded YouTube video? If a website could fake their referer header that could be a security risk

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

>In the bug report I opened to YouTube, I used a nicer set of words.

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).

> 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?

Never had this problem. I'm in Thailand and whether I'm on mobile or Wi-Fi it's always at high quality

I explained them politely what was the issue, and the differences in behavior which led me to conclude why it is a bug and not a feature.

I've noticed this bug before too. Seems like an old one

Reply on news.ycombinator.com