> To clarify it more, it's simply this code in their polymer script link:

> setTimeout(function() { c(); a.resolve(1) }, 5E3);

> which doesn't do anything except making you wait 5s (5E3 = 5000ms = 5s). You can search for it easily in https://www.youtube.com/s/desktop/96766c85/jsbin/desktop_pol...

    h=document.createElement("video");l=new Blob([new Uint8Array([/* snip */])],{type:"video/webm"});
    h.src=lc(Mia(l));h.ontimeupdate=function(){c();a.resolve(0)};
    e.appendChild(h);h.classList.add("html5-main-video");setTimeout(function(){e.classList.add("ad-interrupting")},200);
    setTimeout(function(){c();a.resolve(1)},5E3);
    return m.return(a.promise)})}

    GkXfo59ChoEBQveBAULygQRC84EIQoKEd2VibUKHgQRChYECGFOAZwH/////////FUmpZpkq17GD
    D0JATYCGQ2hyb21lV0GGQ2hyb21lFlSua6mup9eBAXPFh89gnOoYna+DgQFV7oEBhoVWX1ZQOOCK
    sIEBuoEBU8CBAR9DtnUB/////////+eBAKDMoaKBAAAAEAIAnQEqAQABAAvHCIWFiJmEiD+CAAwN
    YAD+5WoAdaGlpqPugQGlnhACAJ0BKgEAAQALxwiFhYiZhIg/ggAMDWAA/uh4AKC7oZiBA+kAsQEA
    LxH8ABgAMD/0DAAAAP7lagB1oZumme6BAaWUsQEALxH8ABgAMD/0DAAAAP7oeAD7gQCgvKGYgQfQ
    ALEBAC8R/AAYADA/9AwAAAD+5WoAdaGbppnugQGllLEBAC8R/AAYADA/9AwAAAD+6HgA+4ID6Q==

    v = document.createElement('video');
    v.src = `data:video/webm;base64,`;
    await new Promise(resolve => v.onloadedmetadata = resolve);
    console.log(v.duration);

What exact combination of circumstances is required to trigger the multi second wait time?

Load: 4.34s, 5.14, 2.96, 3.35

DOMContentLoaded: 3.65s, 4.56, 2.92, 3.33

Finish: 13.14s, 10.77, 8.49, 12.02

So it's getting a bit faster over time, but still heinous, and crucially, it isn't hanging on requests. Individual asset GET/POST requests are taking tens of ms, worst was a few parallel 254ms GETs on a cold start. Usually 50-70ms. But there is a flurry of requests, then a period of very few requests until 5s after init, then another flurry.

Firefox 119.0 Ubuntu 22.04 uBlock Origin, Privacy Badger

Same OS, chrome 115.0.5790.170, no blockers, youtube is much snappier, it still definitely takes a few seconds to paint thumbnails, but it's basically done by 5s. DOMContentloaded is never more than 1.75s, finish

Firefox private window with blockers off has similar time statistics. But actually doubleclick.net is still getting bounced.

Do they serve different js based on the user agent header? If they delay chrome too there's no foul.

https://old.reddit.com/r/firefox/comments/17zdpkl/this_behav...

Like when I noticed that some sites did some URL rewriting trickery on Firefox and others browsers, but not for Chrome. The trick is to show you the proper URL the link points to, but as you click, it is substituted for one that is a redirection, for tracking purposes (ex: "https://l.facebook.com/l.php?u=http:://actualsite..."). On Chrome, they don't need to use these tricks as the browser supports the "ping" attribute of links, so they can do their tracking without rewriting the URL.

There's so much trickery and nonsense around this stuff that no link is safe to just click on.

Thanks for the context!

[0] Unable to press play and showing image with Ad instead.

I'm mad that such a big company with suposelly decent engineers, are making me wait 5s with literally a sleep, how is even possible to do such thing in such a rudimentary way? I would be like damn that was smart, this feels like, seriously this is the level?

    * Marketing/Sales asks engineers to add a feature flag to sleep N milliseconds for their research: "how slowing down impacts your revenue"
    * engineer adds a flag, with different control parameters
    * Some genius in Product figures this out and updates the experiment to slow down for competitors

Engineers tend to create paper trails on what they work on, code reviews and bug logs etc are everywhere, so I doubt there is any of those where they say "Make things shit for Firefox to hurt our competitors", that would net them an easy loss in court. But not testing in browsers with small userbases will hold in court.

Google have been disgustingly anticompetitive for a very, very long time at this point.

[1] https://news.ycombinator.com/item?id=38347364

I have firsthand knowledge that Cloud, for instance, did not test regularly directly on Firefox. Team couldn't justify the cost of setting up and maintaining a FF test suite to satisfy 1 in 50 users, so they didn't (and nobody up-chain pushed back on that). Testing was done regularly on Chrome, Safari, and Edge, as per the usercounts and "top three browser" guidance (at the time, we didn't even test regularly on mobile, since there was a separate mobile client).

But the analytics team? I'm sure they test directly on Firefox. They're just testing an entirely different piece of the elephant and their end-to-ends won't include how, for example, changes they make interoperate with Firefox in the context of Cloud. Or YouTube. Or etc. Not unless they have a specific reason to be concerned enough to.

Google's like any other megacorp in the sense that costs of cross-team coordination are combinatoric.

Another example that springs to mind is Uber, who used a tool called "Greyball" to avoid contact between drivers and authorities: https://www.reuters.com/article/uk-uber-greyball-idUKKBN16B0...

My initial reaction was astonishment that the engineers would happily implement this. And maybe that is what happened. But the alternative possibility is that product and senior management assigned different parts of the feature to different teams e.g. one team develops a pattern recognition system to detect users' professions, another team develops a spoofing system for use in demos, etc...

“Research”

https://blog.research.google/2009/06/speed-matters.html

There are many such tests being written about in blogs today. So now a developer can get time to optimize load times based on those blog posts while before managers would say it was worthless.

It's always, always mattered. If anything, people care less today, with the entire ridiculous 100 loads per page.

Whomever didn't care was weird.

In order for someone to slow down the by browser they need someone to have coded the following:

- UA Detection

- Branching for when the flag is on or off

- a timeout that only runs when these two things are true

That takes an engineer to do the work. Marketing and product managers are not writing this code certainly.

If they’re abusing a differ t flag, then the real question I have is what the flags purpose is and why is it screening Firefox.

Either way there is an intention of UA checking and throttling based on the UA and that takes an engineer to do it

Good engineering isn't about being obtuse and convoluted, it's about making stuff that works.

An engineer doing "good engineering" on a feature typically depends not only on them being a "good engineer" but also on them having some actual interest in implementing that feature.

Plus a Firefox dev would discover that more easily as opposed to this version which they can just dismiss as some JavaScript bug on YouTube's part

The only superior approach here would be one that is consistent enough to be perceived but noisy enough to be robust to analysis.

Also it should be hidden on the server side.

Who knows, maybe there are a bunch of equivalent slow downs on the server side in the Google property space.

Given this discovery it would probably be reasonable to do some performance testing and change the user agent header string of the request.

Google docs, image search and Gmail operations would be the place to hide them.

5 years? 7? Longer?

No matter how they approached it, you could demonstrate the pattern through the law of large numbers regardless. Might as well make the implementation straight forward.

I'm not even a JS programmer but I know about timers, idle wait in UI programming is a common pattern. It's the attitude of mediocre engineers not bothering to lookup or learn new things.

If every OS/browser/stock market dev did what they want "because it works" we don't have a working system. We'll have systemic lags making the system sluggish and eventually unusable as more engineers follow the same mantra.

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/requ...

"It works" is The high engineering bar and it's the hard one to hit.

Oftentimes it's replaced these days with imagined complexity, ideological conformity or some arbitrarily defined set of virtues and then you get a really complicated thing that maybe works some of the time and breaks in really hard to understand ways.

Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks to do a "select *" from a table and then pipe things in the reverse direction to talk to a variety of services and providers with their own APIs and separate dependencies sitting in different microservices as it just shepherds a JSON string through a dozen wrapper functions on 5 docker containers to just send it back to the browser is The way things are done these days. This is the crap that passes for "proper" engineering. Like the programming version of the pre-revolutionary French Court.

A simple solution, fit for purpose, that works as intended, easy to understand, remove, debug and modify with a no-bus factor, that's the actual high end solution, not the spaghetti stacked as lasagna that is software haute couture these days.

Sometimes, in practice, the dumb solution can also be the smart one. True mastery is in what you choose Not to do.

In this particular case I disagree with using `sleep`; using the idle timer it's not as roundabout as you put it: _Transcompiled frameworks inside of microservices talking to DBMS adapters over virtual networks_. It's a straight-forward callback, some lower-level timekeeper signals you and you do your thing: it's nowhere close to the convoluted jumping through hoops you explain.

Mastery comes with balance: putting in the optimal effort, not more, not less either. Of course, depends on what one's trying to master: job or programming. Former means do the minimum and get maximum benefits from your job/boss, latter means enjoy learning/programming and arrive at the most optimal solution (for no reason, just because you're passionate).

If your code needs to wait for something, it's better done with some sort of event system or interrupt or similar; the reason being that a 5s wait is a 5s wait, but if, say the thing you're waiting for returned in 10ms, if you're using an alternative solution you can carry on immediately, not wait the remaining 4.99 seconds. Conversely, if it takes longer than 5s, who knows what happens?

Their goal, quite clearly, is to prevent (or at least heavily discourage) adblockers. This is one attempt to detect them, and maybe in Chrome they have a different detection mechanism so it doesn't show the same behavior.

It would be a particularly foolish move on their part to push Chrome by punishing everything else right now, while they are in the middle of multiple anti-trust lawsuits. It makes me think that is unlikely to be the intent of this change.

But then I think of some alternative method where they send an ajax request to "sleep.google.com/?t=5" and get a response like "" after five seconds.

employees will follow orders, orders are made by people who control the money

So I wonder if that 5s delay has always been there.

Added bonus, I'm less tempted to venture into the comments section...

Edit: I have forgotten to add sponsorblock to the list of extensions

Depending on if you've set up uBlock to auto-update and when you've watched youtube relative to when the block filters got updated you might just not have been hit with the latest detectors while they were active. Personally I know I got the "accept ads or leave" modal with firefox + uBlock, locking me out completely on one of my devices.

I got the you can't use an adblocker message, but was able to close and/or reload the page to watch videos without ads. After a week or so it stopped popping up.

US, Firefox, uBlockOrgin.

Go into ublock origin addon > click filter lists > purge all caches then update now

all done

[1] https://github.com/yuliskov/SmartTube

Curiously it happens only on one profile, in another Chrome profile (which is also logged in to the same Google account) it does not happen. Both profiles run the code in your comment, but the one that does not have the delay does not wait for it to complete.

The only difference I spotted was that the profile that loads slowly does not include the #player-placeholder element in the initial HTML response. Maybe whether it sends it or not is tied to previous ad-blocker usage?

What does piss me off is that even if you clear cookies and local storage and turn off all extensions in both profiles it still somehow "knows" which profile is which, and I don't know how it's doing it.

(Sorry this is heading into the weeds, but I'm not really a web developer so maybe someone can tell me!)

Never seen the use of exponential notation for numbers in js though (not a surprise, I'm not really a programmer), it seems sensible to me from the point of shifting the domain from ms to seconds.

`1==true` but `1!==true` (`===` and `!==` check for type equality as well and while `!0` is a boolean, `1` is not.

Why is there more than one user-agent? Does somebody still expect to receive different content based on the user-agent, and furthermore expect that the difference will be beneficial to them?

What was Microsoft trying to achieve by sending a non-Chrome user-agent?

1. They are useful for working around bugs. You can match the user agent to work around the bugs on known-buggy browser versions. Ideally this would be a handful of specific matches (like Firefox versions 12-14). You can't do feature detection for many bugs because they may only trigger in very specific situations. Ideally this blacklist would only be confirmed entries and manually tested if the new versions have the same problem. (Unfortunately these often end up open-ended because testing each new release for a bug that isn't on the priority list is tedious.)

2. Diagnosing problems. Often times you see that some specific group of user-agents is hammering some API or fails to load a page. It is much easier to track down if this user agent is a precise identifier of the client for which your site doesn't work correctly.

3. Understanding users. For example if you see that a browser you have never heard of is a significant amount of traffic you may want to add it to your testing routine.

But yes, the abuse of if (/Chrome/.test(navigator.userAgent)) { mainCode() } else { untestedFallback() } is a major issue.

It would never do feature detection, would give lower quality h264 video, etc. Back then, there was really nice third-party application myTube which had made this less of an issue but it was eventually killed through API changes.

Uh, yes? We were all inexperienced at some point. Just the linked file is like 300k lines of unminified code, I doubt it's all written by PHDs with 20 years of experience

Yes

This reply is for everyone who has ever worked on the codebase...

There is no reason for charity with such a large power difference. For Firefox, "bugs" like this can really end up being a lost one-shot game.

It's like people walking by and casually reaching for your phone. It's always meant as a joke, unless you don't pull it away fast enough. Then suddenly it wasn't a joke - and your phone is gone.

This is not rooted in any reservation against Google in particular. If you are a mega-corporation with the power to casually crush competitors, you should really want to be held to a high standard. You do not want to be seen as the accidentally-fucking-others-up-occasionally kind of company.

  mpv [--no-video] "https://www.youtube.com/watch?v=X9zVjEZ7W8Q"

I really don't understand why any technically proficient user would willingly use any of the official YouTube frontends. You get bombarded with ads, you're constantly tracked and experimented on, and your behavior is used to improve their algorithms in order to keep you on the site for as long as possible. It's a hostile user experience, just like most of the mainstream web.

Whenever possible, I suggest using Invidious, Piped, Newpipe, yt-dlp, and anything but the official frontends.

I try to compensate the creators I follow via other means if they have an alternative income source, but I refuse to be forced to participate in an exploitative business model that is responsible for the awful state of the modern web.

I'm a technically proficient user that's written custom bash scripts for youtube-dl combined with ffmpeg to download videos locally and I still use the official Youtube desktop web browser UI every day for several reasons:

+ transcripts and close-captioning (use Ctrl+F search for text to find the section of video that starts talking about the topic I'm interested in)

+ many videos have index of chapters (deep links), table-of-contents

+ viewers' comments (especially valuable for crowdsourced feedback on DIY videos to point out extra tips, or flaws, etc)

+ external links mentioned (Amazon links to products is especially valuable for DIY tutorials)

+ convenient hot links to related videos (part 2, part 3, etc). Not every creator makes "playlists"

+ Youtube web UI has superfast video scrubbing of the timeline. A local video player like VLC scrubbing of the timeline is very slow compared to Youtube because the youtube backend pre-analyzes the entire video and generates a bunch of timeline thumbnails at multiple intervals. This makes the Youtube web UI timeline scrubbing very fluid with responsive visual feedback.

I like downloading with yt-dlp but I also lose a lot of functionality when I watch videos in VLC instead of the Youtube desktop webbrowser UI. The above points are not relevant to the terrible Youtube app on mobile and tablets.

I'm not claiming that the OSS tools have feature parity with 1st party frontends, or that they won't require some sacrifices, or effort adjusting. I just think that the trade-off of losing some of the convenience in return for not being tracked and manipulated is well worth it to me, though I can see how it might not be worth it for others.

I do actually think that OSS tools provide a better UX. I can download the media and consume it offline, using any player of choice, on any device, at any time. I find YouTube's recommendations a nuisance, and I can turn those off in Invidious and Piped. Scrubbing in mpv is instantaneous for me for local files and even those served on the LAN, though there is a slight delay when playing directly from YT. There is also a solution for generating thumbnails[1], though I had some issues with it, and didn't end up using it.

At the end of the day, it's a personal choice depending on what you value most, and I'm not trying to convince anyone my choice is inherently better. Thanks for providing your perspective.

[1]: https://github.com/tomasklaen/uosc

Yes, I agree that scrubbing in mpv or vlc is "instantaneous" but Youtube's web ui is even more hyperfast "instaneous" than mpv.

>There is also a solution for generating thumbnails[1], though I had some issues with it, and didn't end up using it.

For me, using an offline tool like thumbfast to generate timeline previews defeats the purpose of using Youtube's pre-existing timeline thumbnails that Google's datacenter already generated. Let me explain...

>I do actually think that OSS tools provide a better UX. I can download the media and consume it offline, using any player of choice, on any device, at any time. I find YouTube's recommendations a nuisance,

I'm guessing it's a difference in usage pattern. I'm often browsing a bunch of Youtube videos as a research tool. Like a "visual wikipedia" for various topics (especially DIY tutorials and products research). I want to jump in and out of videos fast. Downloading videos with yt-dlp to play in mpv isn't the workflow here. That's too slow and cumbersome. Instead, I'm sampling a bunch of videos and maybe a few of those will be ultimately be downloaded. E.g. Preview/scrub fragments of 10 related videos, read some viewer comments, scan some transcripts, etc... and eventually only yt-dlp 2 of them. This is why "mpv yt-dlp with workarounds" is not an acceptable substitute for using Youtube's web ui.

My only usage of YT is queing up videos for short-term playback. So I browse a feed of my subscriptions in Piped, drag links of videos I'm interested in to a text file, and run a small script on my HTPC to download them with yt-dlp in parallel, and add them to a playlist. With a fast connection, it only takes a few minutes to download even dozens of videos at a time. Then I serve the videos on my LAN over HTTP with nginx, and watch them on any of my devices using any media player that can stream HTTP, which is usually mpv.

I started a project some time ago to make this fancier, but honestly, this workflow does 90% of what I need, and I'm too lazy to change it.

To each their own :)

In mpv, you can use PgUp and PgDown to select chapters.

> + external links mentioned

Video description is in audio/video file if yt-dlp gets a --embed-metadata. mpv prints that if present.

- Because I don't see ads with YouTube Premium

- Because I add things to my playlists

- Because I more often than not find interesting things to watch there

- Because I like using it on my phone or TV

There's a lot of reasons why someone would prefer the official apps over some third party app that might break every few months.

I was in that boat. But after a while I realized I could no longer in good conscience give Google any more money when they were pushing so many initiatives that went against my interests.

Of course this only works because by default (since I have an ad blocker anyways) I don't get bombarded with ads on the web frontend, and so far I've seen the adblocker nag screen once (a failure which uBlock Origin seems to have swiftly corrected).

I would much rather put up with Youtube than be frustrated when my 'alternate frontend' one day breaks and i need to figure out a workaround.

That is debatable. I personally find that the combination of Piped, yt-dlp and mpv provides a far better experience than the official frontends. But this is a personal opinion, and I'm not trying to convince anyone my choice is better. I just didn't think other technical users would prefer using the official frontends.

Thanks for your perspective, though I think it's a bit outdated.

> None of those tools worked with Sponsorblock last time I tried, for one.

Piped, yt-dlp and mpv all support Sponsorblock.

https://github.com/marzzzello/mpv_thumbnail_script

Getting familiar with such tools not only replaces the terrible UXes you have to be subjected to, but also gives you the power and freedom to be creative with how you use Youtube and other online streaming sites.

I wrote various tiny scripts to replace all my needs for Youtube search, using any highlighted text, with a shortcut, Youtube Music, with a synced plain text file of song titles and a shuffle-on-read script, and more curiously, a script to help me slowly go through all thousands of my partner's favorite songs, and then, using shortcuts, add them to my own favorites, decide on them later, add them to the "what the heck do you listen to" friendly banter list, or the "my ears bleeding" list, etc. Much better UX then anything the slow web UIs can offer, and with minimum hacking.

[0]: https://ytfzf.github.io/

[1]: https://github.com/yt-dlp/yt-dlp

My post was only about playing videos.

One option is RSS (YouTube still supports it) subscribing to channels. Do you know of others?

Apparently this is due to DRM restrictions, but the frustrating part is that you can pay extra money for the HD version and there's nothing telling you about this not being supported in your browser until you've made the purchase (by just allowing 420p and needing to search for why it's broken)

see https://www.reddit.com/r/youtube/comments/pm0eqh/why_are_my_...

I could see an argument made that a reasonable person would know an offer to be limited to supported platforms, and that the fine print clarifies which platforms are supported. To me, though, I’d draw a line between unsupported due to underlying limitations (e.g. can’t serve 4k video on a NES) and unsupported due to seller-side limitations (e.g. won’t serve 4k without remote attestation). I’d see the former as a reasonable clarification of the offer, and the latter as an unreasonable alteration of the offer.

At the same time... I think the behavior is pretty shitty, just not illegal, in that it takes minor up front effort to resolve. An explicit message along the lines of "You won't be able to watch in higher quality on this browser/device combination. Do you still want to purchase the high quality version for use on another device? You'll still be able to watch either version on this device, just always in low quality" goes a long way.

in which case, why buy it at all? A torrent isn't going to load as fast as what you paid YT for.

BTW modern piracy setups are far more streamlined and easier to manage/use than modern streaming platforms. Assuming you have some tech ability anyway.

Unless you want to rewind the video without it re-buffering...

#1 You cannot stream in a browser on iPadOS anymore. Amazon won't let you, you must use their app.

#2 They don't seem to give a fuck about making sure you're getting a quality stream in their app. Full of artifiacts and horrible compression way more often than is warranted on my symmetric gigabit connection.

So I added it to my Sonarr instance (pirated it legally) and watched it in a browser from there with perfect quality and no pre-stream ads.

Once again: A paid service so bad that it couldn't compete with the pirate experience even if it was free.

Which once again confirms Gabe Newell's statement to be true: "piracy is not a pricing issue. It’s a service issue"

They give you the option to choose between like four, maybe five languages. That's it!

If you want subtitles in any of the other hundred or so languages that they have available, well... no. Just no. Learn one of the four they've picked for you.

If you call their support, they'll gaslight you and mumble something about "copyright", which is patent nonsense. Copyright doesn't restrict Netflix from showing more translations for their own content that they made themselves. They own the copyright on it, which means, literally, that they have the right to do whatever they please with the copy. Including showing the associated subtitles to you.

You see, what actually happened, is that some too-smart UX guy at Netflix couldn't make a language picker look nice for that many options so he asked a too-smart data science (lol) guy to figure out the most common languages for each region.

Here in Australia they picked English, Italian, Vietnamese, Chinese because we have a lot of immigrants from those countries. I'm sure they used very clever algorithms on big data clusters to figure that out. Good job, well done.

Never mind that every other streaming app vendor figured this out. Netflix and their $500K total comp Stanford or wherever graduates couldn't. So they instructed their call centre staff to lie to their customers.

Then they had someone write this idiocy: https://help.netflix.com/en/node/101798

"If subtitles for a title are offered in a language but do not display on your device, try another device."

Oh, oh, I'll go do that right now! Let me try my PC... nope four languages. On the TV? Four languages. Actually, I have a phone... and... oh... four languages.

PS: Thai (only!) subtitles are "special" and use eye-searing HDR maximum white. Like 1,600 nits white that literally leaves green after-images etched into my retina. They have a support page and a pre-prepared set of lies for the support staff to read for that piece of shoddy engineering also.

Did they? Both Prime Video and Disney+ have very very narrow subtitle and audio language choices.

> If you call their support, they'll gaslight you and mumble something about "copyright", which is patent nonsense. Copyright doesn't restrict Netflix from showing more translations for their own content that they made themselves. They own the copyright on it, which means, literally, that they have the right to do whatever they please with the copy. Including showing the associated subtitles to you.

Maybe they mean the subtitles' copyright?

As someone who speaks multiple languages, and has the habit of watching with subtitles in the original language of the content if I speak it; otherwise default to English subtitles with original audio... none of the streaming companies have managed to handle that properly. Way too often the audio is only dubbed (often badly), or only my subtitles in my local language (French) are available, regardless of the original language of the content. I'd rather watch British movies with subtitles in English, not French, thank you very much.

Are you saying it's some sort of challenge beyond the abilities of a Senior Technical Lead with total comp in the seven digits to figure out how to make a list of items more than 4 or 5 entries long? Too many megabytes of JSON to shove down the wire for more?

> Maybe they mean the subtitles' copyright?

They definitely do not. That's not how work-for-hire translations work. You pay someone to translate your shows' subtitles for you, then you own the copyright on that work that you paid for. That's how that works. No weird region-locked silliness.

You can make other languages appear by changing the entire UI language of Netflix, which then shows some other "data driven" subset of the subtitle languages.

But then, the entire UI is in another language, which not everyone watching may understand.

Essentially there are audio-subtitle language combinations that are impossible to achieve, no matter what. That combo may not be common enough to make any top-5 list anywhere.

So if you love someone of a sufficiently small minority, or have an unusual racial makeup in your household, Netflix would rather you weren't so weird.

Sit down and think about how absurd it is for the bastion of wokeness that is Netflix to discriminate this profoundly against inter-racial love. On purpose. They wrote the code to do this.

Blows my mind.

I'm on the same boat and I hear you. And since we are on this subject, do you know what else grinds my gears? The whole idea of cultural appropriation. So if your ancestry is X then you can't do/wear/celebrate Y.

So when you ask these people something like: Is it okay for my half-X, half-Y children to do this? they start feeling confused. But if you go: What about my grandchildren, who are 1/4 X and 1/4 Y and 1/2 Z?. Some of them begin to realize how racist and simplistic they are being.

Learn and enjoy other people's cultures, for goodness' sake. It's called being human.

I've seen similar videos with Japanese garb too. The offendatrons hate it. The actual Japanese people love that you're enjoying their culture.

That is an actual response I've heard more than once.

To be fair, I agree with the "cultural appropriation folks" when they correctly point out that sometimes people intentionally mock other cultures and that's a dick thing to do. But conflating mockery and insult with an appreciation of other cultures is not helpful, and that's what they do in practice.

I'm a Spaniard and when I watch a Japanese person practicing flamenco, I feel flattered, not insulted.

Tell them about the Yugoslav wars merely 30 years ago to blow their minds.

1. Closed captions (CC). Okay, I'm willing to accept they improve the experience of a show / movie for a non-zero number of people. What I absolutely don't accept is CC being the ONLY VERSION OF ENGLISH SUBTITLES available. Either CC or nothing. I can't be the only one who prefers English subtitles for English-spoken media, while NOT needing every single sound described as [wet squelching] or [quirky synth music].

(Bonus points for everyone who recognizes those specific examples ↑)

2. Subtitles in all-caps. For the entire movie. Just why? If I'm able to read the text in time at all (it is widely known that words and sentences in all-caps are slower to read), then I'll just feel everyone's screaming all the time, even if they aren't. Whose idea was this? And also here, to my knowledge it only affects English. (I believe all Nolan movies got this "treatment" for example.)

There have been several occasions where even though it was readily available for me to stream from Netflix, I pirated a show or movie anyway, specifically to avoid one or both of these issues.

I also had this issue, videos would frequently wobble down to like 240p or whatever, on a stable, high speed wired connection.

It's not an internet problem since I never have to buffer when using this forced setting, so it's probably YT trying to save a few bandwidth bucks when they think people aren't looking.

In unrelated news, my youtube-dl usage is way, way up.

0: https://www.pcworld.com/article/398929/youtube-defaults-to-l...