Remix.run Logo
davydm 2 days ago

I haven't seen an issue, but I'm really curious to know what you are experiencing?

wruza 2 days ago | parent [-]

Maybe I got AB tested, cause yesterday-ish all was ok.

When you watch a long VOD part by part, it looks like watch-close-...-watch-close sequence. Youtube normally remembered where you closed the video and then next click on it returned to that time (without any &t=).

Now they added &t=123 everywhere, and when you click on that url, now it becomes &t=123 in history too. And the feed may contain random-timed &t=456 links too.

Now in the third "watch" phase there's a conflict between &t= and what youtube remembered internally, and &t wins, and &t becomes const.

As a result, I watch a couple of hours, close and next time I open &t sends me far back.

For example, I recently closed this video at the time where Simon explained 3-1-1-1 arrow (25:40). But in my history it points to https://www.youtube.com/watch?v=z0rbYbqS4ug&t=691s which is basically the start. (Yes I made sure to ctrl-f5 history page etc etc.) It happens ALL the time now, basically unusable without my script.

solardev 2 days ago | parent [-]

With your script, with the t removed, what happens? Do the videos just start at the beginning now, or is there some internal clock that they start at instead?

wruza 2 days ago | parent [-]

Videos start at where I left them last time, or beginning if never watched. This worked since forever (unless you disable history completely). I believe they store it in localStorage.

Edit: after second thought, maybe they store it on server too. Anyway, everything worked almost perfectly. I could lose a timestamp once a week, but probably due to some packet error.

Someone at YT literally broke what worked, in a way that is so naive and non-web2.0, as if it was made by a php junior from early 2000s. Because e.g. if you open history and newtab a link with &t=, then you have to refresh history now after watching few minutes of the video. And every click makes it worse cause it overwrites internal data too. The original “internal” method worked perfectly because it never relied on a url that may and will become obsolete. Idk why they did that and how it was approved etc.

solardev 2 days ago | parent [-]

Super interesting. Thanks for the details! (I don't work there or anything, was just curious about the implementation)