General DJS Memory Leaks & Potential Voice Issues

These are my current makeCache and sweeper settings within my client:

const client = new Client({
  intents: [
    GatewayIntentBits.Guilds,
    GatewayIntentBits.GuildVoiceStates,
    GatewayIntentBits.GuildMessages,
    GatewayIntentBits.MessageContent
  ],
  shards: getInfo().SHARD_LIST,
  shardCount: getInfo().TOTAL_SHARDS,
  makeCache: Options.cacheWithLimits({
    MessageManager: 0,
    GuildInviteManager: 0,
    GuildEmojiManager: 0,
    GuildStickerManager: 0,
    GuildBanManager: 0,
    GuildScheduledEventManager: 0,
    ReactionUserManager: 0,
    BaseGuildEmojiManager: 0,
    AutoModerationRuleManager: 0,
    ThreadManager: 0,
    ThreadMemberManager: 0,
    GuildTextThreadManager: 0,
    GuildForumThreadManager: 0,
    GuildMemberManager: {
      maxSize: 30,
      keepOverLimit: member => member.id === member.client.user.id
    }
  }),
  sweepers: {
    ...Options.DefaultSweeperSettings,
    users: {
      interval: 3600, // Every hour...
      filter: () => (user: User) => user.id !== user.client.user.id // Remove all users except for bot.
    }
  }
}) as Client & { cluster: ClusterClient<Client> };

const client = new Client({
  intents: [
    GatewayIntentBits.Guilds,
    GatewayIntentBits.GuildVoiceStates,
    GatewayIntentBits.GuildMessages,
    GatewayIntentBits.MessageContent
  ],
  shards: getInfo().SHARD_LIST,
  shardCount: getInfo().TOTAL_SHARDS,
  makeCache: Options.cacheWithLimits({
    MessageManager: 0,
    GuildInviteManager: 0,
    GuildEmojiManager: 0,
    GuildStickerManager: 0,
    GuildBanManager: 0,
    GuildScheduledEventManager: 0,
    ReactionUserManager: 0,
    BaseGuildEmojiManager: 0,
    AutoModerationRuleManager: 0,
    ThreadManager: 0,
    ThreadMemberManager: 0,
    GuildTextThreadManager: 0,
    GuildForumThreadManager: 0,
    GuildMemberManager: {
      maxSize: 30,
      keepOverLimit: member => member.id === member.client.user.id
    }
  }),
  sweepers: {
    ...Options.DefaultSweeperSettings,
    users: {
      interval: 3600, // Every hour...
      filter: () => (user: User) => user.id !== user.client.user.id // Remove all users except for bot.
    }
  }
}) as Client & { cluster: ClusterClient<Client> };

My current issue is that, even with these settings, my bot ends up accumulating a lot of RAM over time (it gets up to 10.5gb at which point, I automatically restart it to ensure server doesn't crash). My bot is in 67k servers and is primarily a voice bot that responds to slash commands and has features that read text messages too. My main hypothesis at the moment is that I am missing a cache/sweeper related setting that is causing many things to be cached when it doesn't need to be, thus causing the increase in RAM over time. Any help is greatly appreciated, and feel free to ask me other questions that can help inform other parameter changes.

74 Replies

d.js toolkit•3mo ago

- What's your exact discord.js npm list discord.js and node node -v version? - Not a discord.js issue? Check out #other-js-ts. - Consider reading #how-to-get-help to improve your question! - Explain what exactly your issue is. - Post the full error stack trace, not just the top part! - Show your code! - Issue solved? Press the button!

dzlandisOP•3mo ago

When I list the processes by running htop (or regular top) it shows different instances of the bot.js file as using the most memory, which I think is to be expected because that is the file that is loaded by the main cluster manager for each cluster. I do have a heap dump from a while ago at this point, but I was never really able to understand the information from it (and I'm not sure if it's still accurate since it's been like almost 2 years now since I did that). I could take another one if you think that's a good avenue to try, but given I wasn't able to gain much from the information last time, I'm a little skeptical. Happy to share the information of the previous one if helpful as a starting point. And as for the recording/playing in voice channels not being freed, again I'm not really sure where to start. I use @discordjs/voice for all that stuff, so I assume the bulk of it is just managed internally by that. I do create a new audio resource each time the user runs one of the commands, but I've always just assumed that JS's garbage collection would clean up the data in the variable at the end of the command file when there are no longer any references to the audio Readable variable. 🤷‍♂️

dzlandisOP•3mo ago

One thing I have noticed that is pretty strange, is I get a lot of these small FFMPEG processes that could be contributing to the issue. In terms of resources, each one uses like 0.1% of memory usage (which I suppose can accumulate with enough processes), and as far as I can tell no CPU usage. May also explain why there were no red flags in the heapdump, as it's a separate process that was likely left unexpected. They seem to be like weird dead static processes? I've looked into it a few time, they always seem to reappear so I've just assumed it's intended behavior of the ffmpeg-static package.

dzlandisOP•3mo ago

The ffmpeg issue has to be a problem with @discordjs/voice then, because I do no manual things with ffmpeg-static except for this one case with prism-media (which is what @discordjs/voice uses internally I believe anyway):

const transcoder = new FFmpeg({
      args: ['-i', 'pipe:0', '-f', 'mp3']
    }) as any;

    const rawAudio = pipeline(readable, transcoder, bufferStream, err => {
      if (err) logger.error(config({ name: 'pipeline' }), err);
    });

    for await (const chunk of rawAudio) {
      buffers.push(chunk);
    }
    rawAudio.destroy();
    transcoder.destroy();

const transcoder = new FFmpeg({
      args: ['-i', 'pipe:0', '-f', 'mp3']
    }) as any;

    const rawAudio = pipeline(readable, transcoder, bufferStream, err => {
      if (err) logger.error(config({ name: 'pipeline' }), err);
    });

    for await (const chunk of rawAudio) {
      buffers.push(chunk);
    }
    rawAudio.destroy();
    transcoder.destroy();

But even here, I destroy the streams so it should theoretically be fine? And the pipe here is pipe:0 whereas in the image I previously attached it is pipe:1 unless there is some weird discrepancy relating to the pipe number for some reason. 🤷‍♂️ And also just realizing, this part is mp3 whereas the other screenshot mentions opus Ah ffmpeg-static is outdated, wasn't aware of that. What should I be using instead though? Windows in dev, linux in prod

dzlandisOP•3mo ago

I always just used ffmpeg-static because that's what the guide said and I thought it would be the easiest across platforms https://discordjs.guide/voice/#installation

discord.js Guide

Imagine a guide... that explores the many possibilities for your discord.js bot.

dzlandisOP•3mo ago

Well interestingly enough, my windows version was using a native install of ffmpeg which I just updated, how about that 👀 And as for on the Linux prod, the only version it has is ffmpeg-static I'll give that a try and see if it makes a difference 👍 So some updates: - The ffmpeg from ffmpeg-static was version 6.0 (newest available version is 7.1) - The newest ffmpeg able to be downloaded natively on Linux on the version of Linux I am running is actually an older version (4.2.7) - Supposedly newer versions of ffmpeg are not supported on my current version of Linux (which perhaps was causing the issue with ffmpeg?) - Will probably update Linux version at some point to download the newest one, but for now, seeing if the native Linux one makes any difference 🤷‍♂️ @Qjuh same issue unfortunately, starting to see some ffmpeg dead process behavior despite using native to system ffmpeg as opposed to ffmpeg-static

dzlandisOP•3mo ago

Think it may be related to this: https://github.com/discordjs/discord.js/issues/8961

GitHub

Audio resource write after end error cause memory leak · Issue #896...

Which package is this bug report for? voice Issue description 1.Play a song using ytdl=>ffmpeg=>audio resource 2.try to get a write after end error 3.ffmpeg process won't shut, ytdl and f...

dzlandisOP•3mo ago

Nope, not using ytdl at all They are streams from elsewhere More specifically, it's a ReadableStream As in, do the opus encoding manually with prism-media and then make that the audio resource? I'll give it a try Welp, I tried following similar steps and wasn't able to get it working :( opus encoding part gave me a generic error

Aus_Karlos•2mo ago

When your using ReadStream from the external source are you handling closing the stream? Sometimes piping a stream to something like ffmpeg doesn't always get handled correctly. I have transcoding server using native ffmpeg which is spawn from a pool of workers (Job with source path -> WorkerPool -> fmpeg (fluent-ffmpeg wrapper) -> 4x threads spawn). When my worker gets a job it reads the file into a stream and ffmpeg does its thing. I've noticed that in some circumstances the stream wont close after ffmpqg has done its thing and I need o make sure i call destroy() on the stream. Its usually Linux that has the memory leak, Windows seems to close the stream properly.

dzlandisOP•2mo ago

@Qjuh@Aus_Karlos let me know your thoughts on this, but I found a somewhat related issue where the solution appears to explain that ffmpeg got stuck because it was waiting for a stream that did not exist. It mentions the an extra dash which indicates streaming... I'm wondering if this could help narrow down the issue... although it may just be a piece of the puzzle of understanding. Just leaving here for future documentation as well: https://github.com/discordjs/discord.js/issues/7232#issuecomment-1685413738

GitHub

AudioPlayer does not play local files if a stream was played before...

Which package is this bug report for? voice Issue description Playing local files is working but there is a corner-case where it isn't. Play a file or something else via a stream Play a file vi...

dzlandisOP•2mo ago

Okay update--I think I may have figured out how to replicate the creation of the ffmpeg dead process. It appears to occur when I play a readable file and then disconnect the bot before it has finished playing. In terms of replicability, based on what I have tried so far, it appears that this is reproducible by playing a readable audio stream of sizable length (larger than just a short like 1 second audio for whatever reason, may need to increase the length as needed for testing) and then disconnecting the bot (either through connection.destroy(), connection.disconnect() or by manually disconnecting the bot via Discord) while it is playing. From what I've gathered so far (from reading other similar issues such as https://github.com/discordjs/discord.js/issues/7232#issuecomment-1685413738), ffmpeg is essentially getting stuck searching for the audio via input audio from STDIN (which is streamed audio) but can't find it because the connection has been destroyed (or something along these lines) and gets stuck. More handling needs to be added to properly kill the ffmpeg process when this happens. I'm hoping this bit of info can help people debug this issue, reproduce it, and come up with a solution.

pat•2mo ago

~~any idea where these are actually being spawned from lol~~ ~~are you creating anything with -analyzeduration anywhere else~~ ~~the pipe:1 could be from prism cause it will automatically append that yes but i doubt ffmpeg would default the other flags~~ actually i found something that could be it that i dismissed earlier it's this https://github.com/discordjs/discord.js/blob/a1d19b909a2678c0f72c5002927b8d43dd28151c/packages/voice/src/audio/TransformerGraph.ts#L165 (and the one 22 lines below) when you don't close the stream it will just continue waiting for new data to be piped in iirc so yep basically right

dzlandisOP•2mo ago

Yes, this makes sense to me. The question I have is how to properly destroy the stream without causing an error relating to killing the stream before it was finished. Destroying it while the audio is playing successfully removed the FFmpeg in my testing, but it also causes an error servere enough that it causes the bot to crash even if I try/catch it.

pat•2mo ago

not really confident that these are whats causing you to hit 10gb tho i can repro leaking absurdly easily if i make a new audioplayer every time i start a song, is that something similar to what you are doing? (i.e. the example uses 1 global audioplayer but obvs not adequate for multiple servers)

dzlandisOP•2mo ago

Yes, I make a new audio player each time someone runs a command (and commands are run frequently) The way my bot works is that someone sends a command, and then a sound is played in the voice channel they are in when it is run.

pat•2mo ago

hmmmmmmmmmm

pat•2mo ago

so this is why they aren't being garbage collected i think changing this is a breaking change? best way to go about it is checking if a player's .playable length becomes 0 and then deleting it from that array, but that makes it unusable in the future @dzlandis okay here's something you can do to fix this in userside code create audioplayer after getting the connection, and before actually creating it, force the old one to stop (or use it if you want idk thats just a bit more complex)

// .. get voice connection ..

if (connection.state.status !== VoiceConnectionStatus.Destroyed && connection.state.subscription) {
  connection.state.subscription.player.stop(true);
}

// .. create new audioplayer ..

// .. get voice connection ..

if (connection.state.status !== VoiceConnectionStatus.Destroyed && connection.state.subscription) {
  connection.state.subscription.player.stop(true);
}

// .. create new audioplayer ..

and also this is assuming that you dont do anything where theres 2 voiceconnections listening to one audioplayer

dzlandisOP•2mo ago

Interesting, got it. I'll give it a try and test it out 👍 And I don't do anything where there are 2 voice connections listening to one audioplayer, so this should work good 👍 ~~Thanks for finding this btw, that explains that.~~ @pat actually, I don't think this is it unfortunately, although if you are able to actually see and replicate the memory leak, that suggests something weird. I had a conversation about player stopping stuff a while ago in https://discord.com/channels/222078108977594368/1267790507866853488 with @Qjuh and based on my understanding, players were being removed from that audioPlayer array, and so garbage collection would do its thing correctly (theoretically). Specifically, this message comes to mind when I was investigating the code previously. Also, it's worth noting that when I do this code with and without the commented portion, the length is always logged as 1 🤷‍♂️

if (connection.state.status !== VoiceConnectionStatus.Destroyed && connection.state.subscription) {
      console.log(connection.state.subscription.player.playable.length);
      // connection.state.subscription.player.stop(true);
      console.log('BREAK');
      console.log(connection.state.subscription.player.playable.length);
    }

if (connection.state.status !== VoiceConnectionStatus.Destroyed && connection.state.subscription) {
      console.log(connection.state.subscription.player.playable.length);
      // connection.state.subscription.player.stop(true);
      console.log('BREAK');
      console.log(connection.state.subscription.player.playable.length);
    }

Also worth noting that I don't await enterstate, so the first time the user runs TTS, this code doesn't run at all, and the second time it actually runs, but I think that was the intended behavior if I am understanding correctly.

pat•2mo ago

they are removed when the player becomes idle, which will prompt the gc length will be like that because that is referring to the old player both times before creating the new one and subscribing it i'm able to get a pretty noticeable increase of memory if i spam the command from voice-examples/examples/basic by moving the audioplayer out of global scope

if (message.content.includes('join')) {
    if (!message.member?.voice.channel) {
        await message.reply('Join a voice channel then try again!');

        return;
    }

    /**
     * The user is in a voice channel, try to connect.
     */
    try {
        const connection = await connectToChannel(message.member.voice.channel);

        /**
         * We have successfully connected! Now we can subscribe our connection to
         * the player. This means that the player will play audio in the user's
         * voice channel.
         */

        if (connection.state.status != 'destroyed' && connection.state.subscription) {
            // @ts-ignore
            // connection.state.subscription.player.stop(true);
        }

        const player = createAudioPlayer();
        player.on("debug", (x) => {
            console.log(`${message.createdTimestamp} ${player.playable.length} ${x}`);
        });

        connection.subscribe(player);
        await playSong(player, 'https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3');

        await message.reply('Playing now!');
    } catch (error) {
        /**
         * Unable to connect to the voice channel within 30 seconds :(
         */
        console.error(error);
    }
}

if (message.content.includes('join')) {
    if (!message.member?.voice.channel) {
        await message.reply('Join a voice channel then try again!');

        return;
    }

    /**
     * The user is in a voice channel, try to connect.
     */
    try {
        const connection = await connectToChannel(message.member.voice.channel);

        /**
         * We have successfully connected! Now we can subscribe our connection to
         * the player. This means that the player will play audio in the user's
         * voice channel.
         */

        if (connection.state.status != 'destroyed' && connection.state.subscription) {
            // @ts-ignore
            // connection.state.subscription.player.stop(true);
        }

        const player = createAudioPlayer();
        player.on("debug", (x) => {
            console.log(`${message.createdTimestamp} ${player.playable.length} ${x}`);
        });

        connection.subscribe(player);
        await playSong(player, 'https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3');

        await message.reply('Playing now!');
    } catch (error) {
        /**
         * Unable to connect to the voice channel within 30 seconds :(
         */
        console.error(error);
    }
}

dzlandisOP•2mo ago

Is there a way to actually read how any players there are somehow? I think I misunderstood what the playable.length part was and was assuming that would show me how many active players there were, and hence the issue with the memory leak with some players existing when they shouldn't. Maybe I'm misunderstanding.

pat•2mo ago

nah its not exported

dzlandisOP•2mo ago

I see Wouldn't this affirm that they are being dealt with correctly then though?

pat•2mo ago

that is what you would want yes but when you subscribe a new audioplayer and don't stop the old one it is put on autopaused, not idle

dzlandisOP•2mo ago

Ah I see

pat•2mo ago

what makes you so confident that it's not this btw

dzlandisOP•2mo ago

I take it back--I think you may be right Cause if the idle state never fires, which I don't think it does (especially in the case where the audio stream gets interrupted), it will never get cleared, which makes perfect sense

pat•2mo ago

30~ seconds of spamming the command later

pat•2mo ago

after stopping bot process

dzlandisOP•2mo ago

Well, makes perfect sense to me haha. Can't argue with that. I'm gonna give it a try in production and report back to see if it makes a noticeable improvement. Will report back findings 👍 But there should probably be an issue opened about this I would imagine. At least to warn people of this issue, cause I don't think it's neccessairly the expected behavior.

pat•2mo ago

an issue for all the 5 people that use /voice :P

dzlandisOP•2mo ago

Lol I can open it if you'd prefer as well haha Am I correct in my understanding that I shouldn't need to do this when disconnecting the bot because destroying the connection will also destroy the player stream? Like if sounds are playing when the disconnect is ran, that player will be destroyed? And by "this", I should clarify, I mean the solution of calling player.stop(true)

pat•2mo ago

can you be more precise in what you mean by disconnect

dzlandisOP•2mo ago

Calling connection.destroy()

pat•2mo ago

hmm it's not obvious from how that function is made

dzlandisOP•2mo ago

Cause my concern is that if the player is only destroyed on idle, then it wouldn't be destroyed then either because idle is not called on disconnect either. Unless there is somewhere else in the code where deleteAudioPlayer is called that I am missing (or some other form of cleanup)

pat•2mo ago

yea looks like destroying connection puts audioplayer on autopaused too which i guess kinda makes sense (as audioplayers are designed to be 1:many with voice connections)

dzlandisOP•2mo ago

But I don't think that is intended behavior, because if the bot disconnects, I have no access to connection anymore, and therefore can't stop the player stream. Or in otherwords, I have to stop the audio player before disconnecting the bot, and otherwise in the event of a manual disconnection not from the code, I'm kinda screwed.

pat•2mo ago

its def the intended behaviour, just questionable in hindsight i guess if you wanna deal with this properly (i.e. i think how hydra intended), what you could do is manage the audioplayers yourself 💀 oh actually

const { createAudioPlayer, NoSubscriberBehavior } = require('@discordjs/voice');

const player = createAudioPlayer({
    behaviors: {
        noSubscriber: NoSubscriberBehavior.Stop,
    },
});

const { createAudioPlayer, NoSubscriberBehavior } = require('@discordjs/voice');

const player = createAudioPlayer({
    behaviors: {
        noSubscriber: NoSubscriberBehavior.Stop,
    },
});

looks like i forgot about this this will make it so you don't need to manually call stop and from a quick test it sets it to idle aswell when the connection is destroyed

dzlandisOP•2mo ago

Ah neat, so I can just do that and I won't need the other stuff and it should resolve the problem in all scenarios?

pat•2mo ago

yep

dzlandisOP•2mo ago

Great, I'll give it a try So one problem, since I don't await enterstate, the first time someone runs the command nothing will play because the connection isn't established. Do you think I should just revert to using await enterstate (i've had issues with it in the past) or should I make it so the first time it joins the voice channel, I just create the player without that added behavior? Main issue with enterstate was that I would get abort errors which would cause the bot to crash :( Eh, I'll give it a try and see if it still causes issues

pat•2mo ago

i dont really get it, why does nothing play the first time?

dzlandisOP•2mo ago

Because I don't await the connection to be established. So my understanding is, because that doesn't happen, there is no subscriber and it doesn't play, as the new behavior describes.

pat•2mo ago

🤔 i don't think that's caused by this

dzlandisOP•2mo ago

Well when I don't use enterState before creating the new player behavior, audio doesn't play the first time the command is run

pat•2mo ago

i just tried both and either works

dzlandisOP•2mo ago

And if I do use enterState before creating the new player, it does play 🤔 Can I see code?

pat•2mo ago

const connection = joinVoiceChannel({
    channelId: message.member.voice.channel.id,
    guildId: message.member.voice.channel.guild.id,
    adapterCreator: createDiscordJSAdapter(message.member.voice.channel),
});

const player = createAudioPlayer({
    behaviors: {
        noSubscriber: NoSubscriberBehavior.Stop,
    }
});

player.on("debug", (x) => {
    console.log(`${message.createdTimestamp} ${player.playable.length} ` + `${x}`);
});

connection.subscribe(player);

const resource = createAudioResource('https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3', { inputType: StreamType.Arbitrary });
player.play(resource);


await message.reply('Playing now!');

const connection = joinVoiceChannel({
    channelId: message.member.voice.channel.id,
    guildId: message.member.voice.channel.guild.id,
    adapterCreator: createDiscordJSAdapter(message.member.voice.channel),
});

const player = createAudioPlayer({
    behaviors: {
        noSubscriber: NoSubscriberBehavior.Stop,
    }
});

player.on("debug", (x) => {
    console.log(`${message.createdTimestamp} ${player.playable.length} ` + `${x}`);
});

connection.subscribe(player);

const resource = createAudioResource('https://www.soundhelix.com/examples/mp3/SoundHelix-Song-1.mp3', { inputType: StreamType.Arbitrary });
player.play(resource);


await message.reply('Playing now!');

(the behavior won't change anything because the player will begin on idle)

dzlandisOP•2mo ago

hmm, let me test some things Well that's weird, it has something to do with the audio resource. When I put in your audio thing (either as a URL or fetching it and turning it into a readable stream, I did both) it works fine But for whatever reason, when I use my audio readable stream, it doesn't work first try 😩 But then after I tested your audio resource, and switched back to mine, it worked with mine And then I rebooted the bot again and it stopped working 💀 I love DJS!

pat•2mo ago

what is your input

dzlandisOP•2mo ago

I think this was a fluke by the way, I tried it again and it didn't happen 🤷‍♂️ One sec Literally just a fetch of an MP3 file turned into a ReadableStream... I'm investigating So it appears to have something to do with the length of the stream for some reason. My audio is shorter then yours and for whatever reason it fails. But since yours is longer it works. I was able to replicate by using a similar audio file but it just being longer. See if you can replicate the problem by using a shorter audio file 🤷‍♂️ Mine was 3 seconds. And for a second it worked with my shorter audio, and then it failed again 😭 My theory would be it has something to do with the time it takes for it to process the audio file before playing

pat•2mo ago

oh yeah it's totally playing it way too fast ic

dzlandisOP•2mo ago

So await enterState it is I guess and just pray the issues I had previously resolve themselves 🤷‍♂️ @pat other problem actually, if you use the longer audio and then call connection.destroy() it gives a Premature close error 😩

Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at OggDemuxer.<anonymous> (node:internal/streams/pipeline:415:29)
    at OggDemuxer.emit (node:events:536:35)
    at emitCloseNT (node:internal/streams/destroy:148:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:89:21)

Error [ERR_STREAM_PREMATURE_CLOSE]: Premature close
    at OggDemuxer.<anonymous> (node:internal/streams/pipeline:415:29)
    at OggDemuxer.emit (node:events:536:35)
    at emitCloseNT (node:internal/streams/destroy:148:10)
    at process.processTicksAndRejections (node:internal/process/task_queues:89:21)

And it throws that when interrupted as well, not just disconnect So the resolving of removing the player correctly has inadvertently caused a premature close issue when the audio is still processing and the player is removed. Which I suppose sort of goes back to this with the ffmpeg stuff haha

pat•2mo ago

i dont actually get this error on my end audioplayer state is playing, i run connection.destroy() and it disconnects, audioplayer state becomes idle (with the stop behavior)

dzlandisOP•2mo ago

Interesting I had only tested using my audio, let me try yours again Oh no wait, I had used yours Well let me verify What ffmpeg version are you using? You can call generateDependencyReport() with @discordjs/voice to figure it out.

pat•2mo ago

ffmpeg -h ffmpeg version n7.1 are you piping it from an audio receive stream

dzlandisOP•2mo ago

Can you do it with the generateDependencyReport just to make sure? Cause if you use something like ffmpeg-static, it may use a different ffmpeg version then the one you have installed

pat•2mo ago

i dont have ffmpeg-static installed

dzlandisOP•2mo ago

Alr nvm then I fetch the audio from a URL and then do this:

const { readable, writable } = new TransformStream();
res.body.pipeTo(writable);
const audio = Readable.fromWeb(readable as ReadableStream<any>);

const { readable, writable } = new TransformStream();
res.body.pipeTo(writable);
const audio = Readable.fromWeb(readable as ReadableStream<any>);

And I believe I have to do it that way because I need to consume the body somehow (which was another potential memory leak issue I had to look into and fix because I was just passing in the body before and not consuming it lol) Also, just tried passing in just the URL again and I didn't get the premature close issue Let me play around some more In fact, it probably has to do something with this because I think when I tested it using your audio, but with fetch, I used this and it causes the error. Let me confirm that though Yep--confirmed that did it

pat•2mo ago

well anyways the error is bc the place you are sending the demuxed audio to got closed before it sent everything

need to consume the body somehow

🧐

dzlandisOP•2mo ago

https://undici.nodejs.org/#/?id=garbage-collection

Node.js Undici

A HTTP/1.1 client, written from scratch for Node.js.

dzlandisOP•2mo ago

If I don't consume it and just pass in the raw res.body, I don't get the error btw So that was definitely the problem The question now is how to properly consume it.

pat•2mo ago

are you sure that passing it into the function isn't sufficient to get it gc'ed later

dzlandisOP•2mo ago

As in, passing res.body into Readable.fromWeb()? I suppose it's possible it may be getting consumed by the actual discord.js audio player stuff 🤔

pat•2mo ago

iirc it puts the readable into a pipeline (well theoretically it has to, to be able to play all of the audio)

dzlandisOP•2mo ago

Yeah, you are right It is getting consumed I confirmed by doing:

const audio = Readable.fromWeb(res.body as ReadableStream<any>);
const resource = createAudioResource(audio);
player.once(AudioPlayerStatus.Idle, () => console.log(res.bodyUsed));

const audio = Readable.fromWeb(res.body as ReadableStream<any>);
const resource = createAudioResource(audio);
player.once(AudioPlayerStatus.Idle, () => console.log(res.bodyUsed));

And it returned true I'll just set it all to use res.body and scrap all that other hacky stuff 👍

pat•2mo ago

as for the other issue i have no idea

dzlandisOP•2mo ago

Fair enough lol

pat•2mo ago

actually i'm curious how you are actually able to get it to play after the first time lol

dzlandisOP•2mo ago

So when I run the command, the bot joins the voice channel and tries to play Because of the way joinVoiceChannel works, since the bot is already in the voice channel, it doesn't try to join again So the connection is already initialized And for whatever reason, it plays once the connection is already initialized That's why I theorized await enterState would fix the issue and make it play the first time since it would wait for the connection to happen. Lmk if that doesn't make sense I've deployed changes to production, will report back about the results. Thanks again for all the help, I really really appreciate it :) And of course, lmk if you figure out that enterState stuff haha So far so good. Of course, the memory still goes up a little as the bot is used and voice channels are joined, but it hasn't gone up so high to where the systemctl process has needed to crash restart yet. Will keep updated :) Real test will be if I can see the systemctl process staying alive for more than like a day. That will confirm to me that the issue has been resolved fully. RAM usage appears to be fluctuating, which I hadn't really seen before and is very promising. Previously RAM would just increase forever and that was that. Now I'm seeing it go up and then go down which is very very good.

pat•2mo ago

how'd it end up going

dzlandisOP•2mo ago

As far as I can tell RAM usage appears to be improved! Issue is hosting has been having networking issues lately so I can't actually tell how long the systemctl process will stay online for at a given time yet. At least for a fact, I know the current crashes aren't RAM/CPU related. I have been getting lots of Abort Errors lately, which I believe are caused by having to reimplement await enterState back into things, but I'm also attributing them to the networking issues the host has been having, so not changing anything yet. Once host fully resolves network inconsistencies, I'll be able to more accurately tell what's going on. I am still concerned that there is a crash occurring, but the error is generic and could either be caused by a cluster crash caused by network issues or a longer running previous issue. Will do my best to keep updated :)

Gaming

Programming

General DJS Memory Leaks & Potential Voice Issues

Did you find this page helpful?