museofficial / muse

🎧 a self-hosted midwestern Discord music bot that doesn't suck
MIT License
859 stars 224 forks source link

Sign in to confirm you're not a bot #1049

Open DrNefarius opened 1 month ago

DrNefarius commented 1 month ago

What's happening? With the newest version, I get the message "Sign in to confirm you're not a bot" whenever I try to play a song. Example command: /play query: https://www.youtube.com/watch?v=lgh68Swuak0

Logs

  muse Error: Sign in to confirm you’re not a bot
  muse     at privateVideoError (/usr/app/node_modules/@distube/ytdl-core/lib/info.js:91:12)
  muse     at exports.getBasicInfo (/usr/app/node_modules/@distube/ytdl-core/lib/info.js:54:22)
  muse     at process.processTicksAndRejections (node:internal/process/task_queues:95:5) +552ms

Screenshots

image

Runtime I'm running Muse:

Versions

Stealthii commented 1 month ago

This is a wider issue affecting many other bots using Youtube's API.

It seems like the cobalt client implemented OAuth tokens to circumvent this: https://github.com/imputnet/cobalt/pull/558

Our issue is that ~ytsr (now no longer supported)~ @distube/ytsr (used as of #1024) does not use any OAuth or API tokens for the search requests.

A couple ways of tackling this:

arty01238 commented 1 month ago

I'm also experiencing this issue!

kwatman commented 1 month ago

I also have this problem.

NYCITGuy commented 1 month ago

I also have this problem! Same configuration

MiguelCollado commented 1 month ago

Hi! I'm currently trying to figure it out, based on the comment @Stealthii made. Apparently, there is no issue with @distube/ytsr, (from what I have just tested, the search part is just OK). I think the problem revolves around ytdl instead, when it tries to get the audio stream.

That ytdl call to fetch for the info has no apiKey whatsoever, so maybe there is an alternative? I dunno, I'll keep trying to solve this issue

Fheuef commented 1 month ago

I'm also experiencing this, even when trying to play songs from Spotify weirdly enough.

In case it's relevant, just before having this error, the bot was acting weird when trying to play a song.

MuazAlhaidar commented 1 month ago

Currently experiencing this issue when hosting the Jmusicbot app on PebbleHost image

From the Console [[INFO]] [JMusicBot]: Loaded config from /config.txt [[INFO]] [Settings]: serversettings.json will be created in /serversettings.json [[INFO]] [JDA]: Login Successful! [[INFO]] [WebSocketClient]: Connected to WebSocket

[23:27:44] [[INFO]] [JDA]: Finished Loading! [[ERROR]] [SignatureCipherManager]: Problematic YouTube player script /s/player//player_ias.vflset/en_GB/base.js detected (issue detected with script: no n function match). Dumped to /tmp/lavaplayer-yt-player-script.js

The command I ran: ?p https://youtu.be/a_aIaO88rzY?feature=shared

Fheuef commented 1 month ago

Still unable to play anything, though now it does log WARNING: @distube/ytdl-core is out of date! Update with "npm install @distube/ytdl-core@latest" when requesting a song.

This is using the latest version with Docker Compose so I'm unable to run this before the container starts, will try tomorrow to install it manually.

GrantBirki commented 1 month ago

Getting the exact same issue as well

Fheuef commented 4 weeks ago

To add more info here (gathered mostly from the links above), this appears to be an IP block from youtube. Apparently it can even happen because a neighboring IP spammed the youtube API too much.

I can confirm that, while my VPS has been unable to play anything for more than a month, I was able to play songs from both youtube and spotify when running the bot on my own PC.

Some users on other projects were able to access the API with rotating IPv6, cookies from an account that is currently logged in, using a proxy, or with OAuth 2.

I haven't found any workaround that we could use so far, besides running the bot on a entirely different IP.

jedichrome commented 3 weeks ago

Just updated to the latest build and getting this as well.

jedichrome commented 3 weeks ago

I got around this by making Muse dependent on Warp. Found the workaround here: https://github.com/jagrosh/MusicBot/issues/1588

    network_mode: "service:warp"
    depends_on:
      - warp
  warp:
    image: caomingjun/warp
    restart: unless-stopped
    ports:
      - '1080:1080'
    environment:
      - WARP_SLEEP=2
      # - WARP_LICENSE_KEY= # optional
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - ./data:/var/lib/cloudflare-warp
karmirith commented 3 weeks ago

I got around this by making Muse dependent on Warp. Found the workaround here: jagrosh/MusicBot#1588

    network_mode: "service:warp"
    depends_on:
      - warp
  warp:
    image: caomingjun/warp
    restart: unless-stopped
    ports:
      - '1080:1080'
    environment:
      - WARP_SLEEP=2
      # - WARP_LICENSE_KEY= # optional
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - ./data:/var/lib/cloudflare-warp

How do I make this work within my Docker application?

jedichrome commented 3 weeks ago

How do I make this work within my Docker application?

Just append the above to your docker-compose.yml for Muse and then run docker-compose up -d

In the end it should look similar to this:

version: '3.4'

services:
  muse:
    image: ghcr.io/museofficial/muse:latest
    restart: always
    volumes:
      - ./muse:/data
    environment:
      - DISCORD_TOKEN=
      - YOUTUBE_API_KEY=
      - SPOTIFY_CLIENT_ID=
      - SPOTIFY_CLIENT_SECRET=
    network_mode: "service:warp"
    depends_on:
      - warp
  warp:
    image: caomingjun/warp
    container_name: warp
    restart: always
    ports:
      - '1080:1080'
    environment:
      - WARP_SLEEP=2
      # - WARP_LICENSE_KEY= # optional
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - ./data:/var/lib/cloudflare-warp
EugeneLeclerc commented 3 weeks ago

I got around this by making Muse dependent on Warp. Found the workaround here: jagrosh/MusicBot#1588

Thanks for the fix! Should we merge this into Muse? The IP-banning from Youtube looks like it will stay, so we need a long term solution.

arty01238 commented 2 weeks ago

How do I make this work within my Docker application?

Just append the about to your docker-compose.yml for Muse and then run docker-compose up -d

In the end it should look similar to this:

version: '3.4'

services:
  muse:
    image: ghcr.io/museofficial/muse:latest
    restart: always
    volumes:
      - ./muse:/data
    environment:
      - DISCORD_TOKEN=
      - YOUTUBE_API_KEY=
      - SPOTIFY_CLIENT_ID=
      - SPOTIFY_CLIENT_SECRET=
    network_mode: "service:warp"
    depends_on:
      - warp
  warp:
    image: caomingjun/warp
    container_name: warp
    restart: always
    ports:
      - '1080:1080'
    environment:
      - WARP_SLEEP=2
      # - WARP_LICENSE_KEY= # optional
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - ./data:/var/lib/cloudflare-warp

I can vouch that this works for me! Though I assume they will find a way to implement it into the project overall?

Hazzajenko commented 2 weeks ago

Is this issue still present in muse v2.9.3 or v2.9.4?

The recent update to @distube/ytdl-core in v2.9.3 has addressed various problems.

EugeneLeclerc commented 2 weeks ago

Is this issue still present in muse v2.9.3 or v2.9.4?

The recent update to @distube/ytdl-core in v2.9.3 has addressed various problems.

Yeah, this is not a @distube/ytdl-core issue. Youtube is blocking IPs, there is nothing that can be done on yt-dlp's end, you just have to get an unbanned IP or route your requests through something else (like Warp).

P529 commented 1 week ago

How do I make this work within my Docker application?

Just append the about to your docker-compose.yml for Muse and then run docker-compose up -d In the end it should look similar to this:

version: '3.4'

services:
  muse:
    image: ghcr.io/museofficial/muse:latest
    restart: always
    volumes:
      - ./muse:/data
    environment:
      - DISCORD_TOKEN=
      - YOUTUBE_API_KEY=
      - SPOTIFY_CLIENT_ID=
      - SPOTIFY_CLIENT_SECRET=
    network_mode: "service:warp"
    depends_on:
      - warp
  warp:
    image: caomingjun/warp
    container_name: warp
    restart: always
    ports:
      - '1080:1080'
    environment:
      - WARP_SLEEP=2
      # - WARP_LICENSE_KEY= # optional
    cap_add:
      - NET_ADMIN
    sysctls:
      - net.ipv6.conf.all.disable_ipv6=0
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - ./data:/var/lib/cloudflare-warp

I can vouch that this works for me! Though I assume they will find a way to implement it into the project overall?

I've tried to set up muse to run with this but the moment I start it with Warp I just get timed out when trying to queue anything. Without warp the bot doesnt time out but I also have the problem of youtube not allowing my connection.

EugeneLeclerc commented 1 week ago

I've tried to set up muse to run with this but the moment I start it with Warp I just get timed out when trying to queue anything. Without warp the bot doesnt time out but I also have the problem of youtube not allowing my connection.

Same for me, Warp worked perfectly for a week, and now I have timeout issues.