Update ytdl-core, @discordjs/opus and @discordjs/voice. Update to Node 22

[Rob4001]

Closes #1241
Closes #1239
Closes #1238

• Updated ytdl-core to 4.16.5 distubejs/ytdl-core@4.15.9...4.16.6 which includes distubejs/ytdl-core@1f57d78 fixing the sig parsing
• ytdl-core dropped node 18 support distubejs/ytdl-core@60f0ab1 so updated to latest Node LTS 22
• Updated to @discordjs/opus v0.10.0 for Node 22 support
• Updated to @discordjs/voice v0.18.0 to remove support for depricated encryption https://github.com/discordjs/discord.js/releases/tag/%40discordjs%2Fvoice%400.18.0

[codetheweb]

📦 🤖 A new release has been made for this pull request.

To play around with this PR, pull ghcr.io/museofficial/muse:pr-1240.

Images are available for x86_64 and ARM64.

Latest commit: 69d2b0b

[Rob4001]

This is 100% a copy of #1221 but with the latest patch version which includes another round of sig parsing changes.
also bumped to Node 22 as it is the current LTS

[SuperKali]

this pr not fix the issue:

muse  | Found 1 successful responses from clients
muse  | WARNING: Could not parse n transform function.
muse  | Please report this issue by uploading the "1743180403637-base.js" file on https://github.com/distubejs/ytdl-core/issues/144.
muse  | /usr/app/node_modules/discord.js/node_modules/@discordjs/rest/src/lib/handlers/Shared.ts:152
muse  | 			throw new DiscordAPIError(data, 'code' in data ? data.code : data.error, status, method, url, requestData);
muse  | 			      ^
muse  |

[Rob4001]

Updated ytdl-core again,
Hopefully will also close #1241

[home-shake]

No container errors, the /play command shows the embed and the bot joins, but music does not play, and the bot disconnects from the channel soon after.

[Yamidavie]

No container errors, the /play command shows the embed and the bot joins, but music does not play, and the bot disconnects from the channel soon after.

Same here, no logs either. Possibly a player issue, what is the significance of that change to the player.ts? Is possible it needs to be passed as string for usage?

[JoeWHoward]

I pulled this down locally and it worked both when ran straight from yarn dev as well as in a docker container.

Approving & merging, thanks for taking the time to do this.

[codetheweb]

🚀 Released in Release v2.11.0.

[JoeWHoward]

muse:latest should be working properly now, it's working in my server at the moment.

A reminder to do a fresh pull of the image if you're using a docker container management service (e.g. Dockge or Portainer)

[SuperKali]

Is it just me or does it still not work? I mean, the bot joins the voice channel but doesn't play anything.

[Rob4001]

Hey, sounds more like an opus/ffmpeg issue, I get similar when something messes up in the stream. Are you running arm or x86 arch, as I was only able to test x86

[SuperKali]

Are you running arm or x86 arch, as I was only able to test x86

I'm using arm64

[Rob4001]

Are you running arm or x86 arch, as I was only able to test x86

I'm using arm64

Ah, that might be the issue, I will brush off an rpi to see if it's an arm64 issue

[SuperKali]

@Rob4001 i think this is the issue: distubejs/ytdl-core#236

[Rob4001]

So I have confirmed it's not an arm64 issue, as it runs fine on my rpi.

The issue is probably an environmental one... further debugging on the 1 vs 2 "Found X successful responses from clients" essentially is caused by google blocking certain API calls from IP addresses which have been flagged as "potential bots".

Interestingly my local IP is returning "UnrecoverableError: Sign in to confirm you’re not a bot" on the "IOS" and "TV" clients, while returns results for "WEB_EMBEDDED" and "ANDROID" because I actively use the youtube apps on my android and browser while logged in from the same IP.

In your case the remaining client may be one which doesn't support opus audio, so can't find a valid format from that source.

You may be able to "unblock" your IP address by accessing youtube logged in from that IP. This may be difficult from a remote server, but you could try VNC or x-server forwarding a browser window.

[SuperKali]

You may be able to "unblock" your IP address by accessing youtube logged in from that IP. This may be difficult from a remote server, but you could try VNC or x-server forwarding a browser window.

The bot is hosted from my home with the same IP as me, to me youtube goes from both browser and app, so that's not the problem. did you check the issue linked above? it would seem that some people go and some people don't and as a result you are not having problems but I am.

[eFlick]

Is it just me or does it still not work? I mean, the bot joins the voice channel but doesn't play anything.

I was able to fix this by deleting the local database attached to Muse. (after this ytdl-core update)

Its location is determined by the -v volume you launch Muse with for Docker. For example, mine is docker run -it -v ${pwd}/data:/data where the volume is defined as a mapping from a home directory to container directory like /home:/container. ${pwd}/data for me on Windows is Users/Erik/Data. I deleted that and then music played. Not sure if this was a coincidence.

[Yamidavie]

Is it just me or does it still not work? I mean, the bot joins the voice channel but doesn't play anything.

I was able to fix this by deleting the local database attached to Muse. (after this ytdl-core update)

Its location is determined by the -v volume you launch Muse with for Docker. For example, mine is docker run -it -v ${pwd}/data:/data where the volume is defined as a mapping from a home directory to container directory like /home:/container. ${pwd}/data for me on Windows is Users/Erik/Data. I deleted that and then music played. Not sure if this was a coincidence.

For me this issue didn't get resolved by that sadly. I created an issue with more details.

[SuperKali]

@Yamidavie Now I don't feel alone 🙃