978
Google just broke all third-party YT clients, including yt-dlp; a full JS implementation is now required. (github.com)
submitted 1 year ago* (last edited 1 year ago) by to c/technology@lemmy.world
276 comments fedilink hide all child comments
 

cross-posted from: https://lemmy.org/post/1872634

So, starting now, Google started mandating full JS for YT, effectively breaking all third-party clients and locking the site to their official client.

This reeks of DRM.

UPDATE: Installing Deno and installing yt-dlp through PyPi fixes yt-dlp but the very idea that Google is mandating JS to lock down YT in an attempt at pseudo-DRM is still crappy.

UPDATE #2: inv.nadeko.net is working again for now.

you are viewing a single comment's thread
view the rest of the comments
[–] 27 points 1 year ago (9 children)

This reeks of same shit different day or at least different month. Last time if I recall you had to include a valid cookie with yt-dlp.

  • permalink
  • fedilink
  • source
  • hideshow 9 child comments
    •
  • [–] 4 points 1 year ago (7 children)

    I've never had to "include a valid cookie", though there's been various problems and they can vary from video to video.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 7 child comments
    •
  • [–] 5 points 1 year ago (5 children)

    Any IP on the local ISP requires a google login to work. Very few work without the cookie generated from it.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 2 points 1 year ago (3 children)

    Weird. I haven't downloaded anything for a month or so (other than running into a different issue on somesomething), but I haven't had to do that for any video for the several years I've been downloading.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 year ago (2 children)

    Is this maybe much more common on common VPN IPs? Not what I think you meant by "local ISP", but would make a lot more sense to me.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 year ago* (last edited 1 year ago)

    It wasn't that way until earlier this year. I switched to a vpn to get around it. I'm using non US VPS in a country that is less tolerant of googles bullshit.

    To be clear the cable IPs are a /20 block that was routed to the cable companies predecessor in 2016. I'm the one who put in the request with ARIN. The new company that acquired this system was bought out by yet another company before the sale went through. I just looked and Cable one has purchased a large stake late last year. All in all it still works okay. Their support though is clueless due to flowchart ignorance. The plant OPs guy stayed the same and he knows how to keep the levels balanced and noise out.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 1 year ago*

    It is definitely more common on VPN IPs, since Google likely identifies the outgoing address as a datacentre, and gets suspicious. I've had multiple issues with the bot sign-in screen when using a VPN for it, whereas not using a VPN doesn't have those problems.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 1 year ago

    I use Seal. It works fine. It has trouble downloading from "official" pages though (e.g. Vevo or Universal or whatever). It's like those pages, since they're owned by corporate entities, have some extra protection on them or something. It's been like this for years, across Android, Windows, Mac, etc -- doesn't matter what I try to use to download, it'll fail on those pages/accounts.

  • permalink
  • fedilink
  • source
  • parent