The song seems to loads but doesnt play🐛

[rockrevenchy]

Describe the bug Everything goes as expected until the very moment you would expect the bot to start playing the sound, it logs in and replies to my /play command correctly but the green circle never appears, no sound is heard and /nowplaying shows the bot hanging at 00:00:00 time as if its paused, /resume, restarting, adding another song etc. doesnt rectify this issue, I feel it may have a problem obtaining the files from youtube.

How To Reproduce Steps to reproduce the behavior: 1.run latest version 2./play any song

Expected behavior self explanatory (id like it to play the song after it logs in and acknowledge the request)

Environment (add if possible)

• Node.js version: 20.14.0 (ALTHO it should be noted, I was originally on version 16, then I tried 18 and am now at the version 20 while testing for this issue, just in case) OS: Debian GNU/Linux 11 (bullseye) aarch64 Host: Raspberry Pi 400 Rev 1.1 Kernel: 5.15.84-v8+ CPU: BCM2835 (4) @ 1.800GHz

No docker, runs on bare metal

Additional information & screenshots I've updated the files using npm update twice, it would seem all packages are up to date

[rockrevenchy]

the console doesnt show any error whatsoever also

[rockrevenchy]

Also also, this installation used to work about 4-5 days ago just fine for the last year, this issue only appeared as of today to my knowledge

[Serdjd]

I have a similar error

/node_modules/@discordjs/rest/dist/index.js:719 throw new DiscordAPIError(data, "code" in data ? data.code : data.error, status, method, url, requestData); ^ DiscordAPIError[10062]: Unknown interaction at handleErrors (/node_modules/@discordjs/rest/dist/index.js:719:13) at process.processTicksAndRejections (node:internal/process/task_queues:95:5) at async BurstHandler.runRequest (/node_modules/@discordjs/rest/dist/index.js:820:23) at async _REST.request (/node_modules/@discordjs/rest/dist/index.js:1256:22) at async ChatInputCommandInteraction.reply (/node_modules/discord.js/src/structures/interfaces/InteractionResponses.js:111:5) at async Object.execute (/dist/commands/play.js:41:13) { requestBody: { files: [], json: { type: 4, data: { content: '⏳ Loading...', tts: false, nonce: undefined, embeds: undefined, components: undefined, username: undefined, avatar_url: undefined, allowed_mentions: undefined, flags: undefined, message_reference: undefined, attachments: undefined, sticker_ids: undefined, thread_name: undefined } } }, rawError: { message: 'Unknown interaction', code: 10062 }, code: 10062, status: 404, method: 'POST', url: 'https://discord.com/api/v10/interactions/1252006958374850623/aW50ZXJhY3Rpb246MTI1MjAwNjk1ODM3NDg1MDYyMzpmM3dUWUg5WnM2Mk5sbHpGek8wdGtudzNMRmxZOWNGaVd1WE1kQ3h0bmJSUWk1V1cwYXgxN0pFd05vYXU3dmd1dXJaR1hpV0ZscFFndzVWTWNwazZPZnJxakZZQ1ZuM1NDN3ExMTN3Q21jaHpPWEhsejNURjliRlFFUlhGOTZYTQ/callback' }

[Eric-Schubert]

I have the same problem. The difference is that I run the bot via Docker.

Even a repull of the imges does not bring any change. The problem possibly seems to be on the YT side.

[lectral]

Yup, can confirm. Bot no longer works.

[crackodille]

Same issue.

EDIT: the problem is that makeResource() uses play-dl which seems to have a problem today and be stuck on buffering.

EDIT2: for example changing play-dl to ytdl-core (install firsst) starts the resource replay:

 public async makeResource(): Promise<AudioResource | void> {
    let playStream;

    const source = this.url.includes("youtube") ? "youtube" : "soundcloud";

    if (source === "youtube") {
      playStream = ytdl(this.url, { filter: "audioonly", liveBuffer: 0, quality: "lowestaudio" });
    }

    if (!stream) return;

    if (!playStream) throw new Error("No stream found");

    return createAudioResource(playStream, { metadata: this, inlineVolume: true });
  }

[rockrevenchy]

interesting, that would be a very decent fix until the bot gets a proper update

(ran npm install ytdl-core and edited my song.ts according to your fix, works flawlessly)

[dlpnd]

Confirming, @crackodille fix works

However its very breakupy, and buffery, it constantly stops and speedups

[hoangvu12]

any updates on this?

[dlpnd]

@crackodille

I've ran a long video, and bot seems to crash with the new package

2024-06-19 09:46:55 AudioPlayerError: aborted
2024-06-19 09:46:55     at connResetException (node:internal/errors:720:14)
2024-06-19 09:46:55     at TLSSocket.socketCloseListener (node:_http_client:461:19)
2024-06-19 09:46:55     at TLSSocket.emit (node:events:529:35)
2024-06-19 09:46:55     at node:net:350:12
2024-06-19 09:46:55     at TCP.done (node:_tls_wrap:614:7) {
2024-06-19 09:46:55   resource: AudioResource {
2024-06-19 09:46:55     playStream: Encoder {
2024-06-19 09:46:55       _readableState: [ReadableState],
2024-06-19 09:46:55       _events: [Object: null prototype],
2024-06-19 09:46:55       _eventsCount: 5,
2024-06-19 09:46:55       _maxListeners: undefined,
2024-06-19 09:46:55       _writableState: [WritableState],
2024-06-19 09:46:55       allowHalfOpen: true,
2024-06-19 09:46:55       encoder: null,
2024-06-19 09:46:55       _options: [Object],
2024-06-19 09:46:55       _required: 3840,
2024-06-19 09:46:55       _buffer: null,
2024-06-19 09:46:55       [Symbol(kCapture)]: false,
2024-06-19 09:46:55       [Symbol(kCallback)]: [Function: bound onwrite]
2024-06-19 09:46:55     },
2024-06-19 09:46:55     edges: [ [Object], [Object], [Object] ],
2024-06-19 09:46:55     metadata: Song {
2024-06-19 09:46:55       url: 'https://www.youtube.com/watch?v=1_N02vM3pyk',
2024-06-19 09:46:55       title: 'Dub Techno Session #38',
2024-06-19 09:46:55       duration: 5613
2024-06-19 09:46:55     },
2024-06-19 09:46:55     volume: VolumeTransformer {
2024-06-19 09:46:55       _readableState: [ReadableState],
2024-06-19 09:46:55       _events: [Object: null prototype],
2024-06-19 09:46:55       _eventsCount: 5,
2024-06-19 09:46:55       _maxListeners: undefined,
2024-06-19 09:46:55       _writableState: [WritableState],
2024-06-19 09:46:55       allowHalfOpen: true,
2024-06-19 09:46:55       _readInt: [Function (anonymous)],
2024-06-19 09:46:55       _writeInt: [Function (anonymous)],
2024-06-19 09:46:55       _bits: 16,
2024-06-19 09:46:55       _bytes: 2,
2024-06-19 09:46:55       _extremum: 32768,
2024-06-19 09:46:55       volume: 1,
2024-06-19 09:46:55       _chunk: null,
2024-06-19 09:46:55       [Symbol(kCapture)]: false,
2024-06-19 09:46:55       [Symbol(kCallback)]: [Function: bound onwrite]
2024-06-19 09:46:55     },
2024-06-19 09:46:55     encoder: Encoder {
2024-06-19 09:46:55       _readableState: [ReadableState],
2024-06-19 09:46:55       _events: [Object: null prototype],
2024-06-19 09:46:55       _eventsCount: 5,
2024-06-19 09:46:55       _maxListeners: undefined,
2024-06-19 09:46:55       _writableState: [WritableState],
2024-06-19 09:46:55       allowHalfOpen: true,
2024-06-19 09:46:55       encoder: null,
2024-06-19 09:46:55       _options: [Object],
2024-06-19 09:46:55       _required: 3840,
2024-06-19 09:46:55       _buffer: null,
2024-06-19 09:46:55       [Symbol(kCapture)]: false,
2024-06-19 09:46:55       [Symbol(kCallback)]: [Function: bound onwrite]
2024-06-19 09:46:55     },
2024-06-19 09:46:55     audioPlayer: AudioPlayer {
2024-06-19 09:46:55       _events: [Object: null prototype],
2024-06-19 09:46:55       _eventsCount: 2,
2024-06-19 09:46:55       _maxListeners: undefined,
2024-06-19 09:46:55       _state: [Object],
2024-06-19 09:46:55       subscribers: [Array],
2024-06-19 09:46:55       behaviors: [Object],
2024-06-19 09:46:55       debug: [Function (anonymous)],
2024-06-19 09:46:55       [Symbol(kCapture)]: false
2024-06-19 09:46:55     },
2024-06-19 09:46:55     playbackDuration: 893900,
2024-06-19 09:46:55     started: true,
2024-06-19 09:46:55     silencePaddingFrames: 5,
2024-06-19 09:46:55     silenceRemaining: -1
2024-06-19 09:46:55   }
2024-06-19 09:46:55 }

[rockrevenchy]

I ASSUME this is the issue that causes the current problem on play-dl https://github.com/play-dl/play-dl/issues/371

edit: I just read the comment in the pull request pointing to this issue, my bad lol

[zarigata]

Same issue.

EDIT: the problem is that makeResource() uses play-dl which seems to have a problem today and be stuck on buffering.

EDIT2: for example changing play-dl to ytdl-core (install firsst) starts the resource replay:

 public async makeResource(): Promise<AudioResource | void> {
    let playStream;

    const source = this.url.includes("youtube") ? "youtube" : "soundcloud";

    if (source === "youtube") {
      playStream = ytdl(this.url, { filter: "audioonly", liveBuffer: 0, quality: "lowestaudio" });
    }

    if (!stream) return;

    if (!playStream) throw new Error("No stream found");

    return createAudioResource(playStream, { metadata: this, inlineVolume: true });
  }

how can i edit that in docker?

[Mkreidly91]

any updates? same issue here :( no errors whatsoever, but it seems that the stream data is empty.

[rockrevenchy]

It seems a lot of bots, api and other apps aiming to download YouTube videos rn are having problems, with the changes Google is pushing, i believe we'll have a rough road ahead

We may need to look towards other sources such as SoundCloud soon for discord bots

[SugarD-x]

It seems a lot of bots, api and other apps aiming to download YouTube videos rn are having problems, with the changes Google is pushing, i believe we'll have a rough road ahead

We may need to look towards other sources such as SoundCloud soon for discord bots

This has been an ongoing battle for many years with YouTube, including at one point Google/YouTube going after package authors and issuing DMCA takedowns on their projects here on GitHub. I'm honestly not surprised, and this seems to come in waves. Unfortunately for me, even the pull request version is not working, as I am getting 429 errors on the first try. It looks like this will be another long-winded fight with YouTube again.

[rockrevenchy]

I have not tested this fork but someone in the comments of this issue submitted their fork of play-dl which works thru the ios extractor, seems to be a good workaround for now from my understanding

https://github.com/play-dl/play-dl/issues/370

https://github.com/YuzuZensai/play-dl-test/commit/2bfbfe6decd68261747ba55800319f9906f12b03

[zarigata]

It seems a lot of bots, api and other apps aiming to download YouTube videos rn are having problems, with the changes Google is pushing, i believe we'll have a rough road ahead We may need to look towards other sources such as SoundCloud soon for discord bots

This has been an ongoing battle for many years with YouTube, including at one point Google/YouTube going after package authors and issuing DMCA takedowns on their projects here on GitHub. I'm honestly not surprised, and this seems to come in waves. Unfortunately for me, even the pull request version is not working, as I am getting 429 errors on the first try. It looks like this will be another long-winded fight with YouTube again.

youtube : use our plataform, it is the best also youtube : I WILL SUE AND TAKE DOWN ALL PEOPLE THAT USES OUR PLATAFORM IN A SLIGHT MISFORM OF WHAT WE WANT

[asmdrk]

Had a similar problem, my bot which used play-dl is no longer working.

Interestingly, it seems to work fine for me when I try to play livestreams(like 24/7 lofi streams for example)

[EduardoJGilA]

Someone have 403 error too?

[Eric-Schubert]

The error is related to the node modules that are used.

Currently it seems that the maintainers of the modules do not take proper action to adapt them. (no accusation) Youtube (Google) has made several adjustments which make the functionality of these modules rendered useless

I have switched to writing my own bot with Python. There are currently still libraries that work. At least for Python

If there is interest, the code can be made public. (It is absolute Early code and does not have all features yet)

Unfortunately I have no hope that the required node modules will be fixed in time.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[SugarD-x]

I'm a little confused as to why the bot closed this as "completed". I get that it auto-closes stale discussions, but that doesn't seem like the correct status for something that hasn't been fixed yet.

[rockrevenchy]

to be completely honest, I believe the entire repository is now abandonned, while this issue is still very real I dont think its gonna get fixed any time soon

[SugarD-x]

to be completely honest, I believe the entire repository is now abandonned, while this issue is still very real I dont think its gonna get fixed any time soon

No disagreement there. The author is active on their own private repos, but clearly isn't doing anything with this right now.