Listening to Player Events + Removing References + player.stop() & Memory Leaks
Should I be concerned about memory leaks if I open a new listener to listen to the player 'playing', 'idle' and 'error' events every time my user runs a command? Or should I not worry about it if I just don't do anything with that player ever again after the user runs the command?
Furthermore, should I be closing players somehow? Or is that just automatic when the player goes to idle after a given period of time? 🤔
6 Replies
- 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!Okay, I think I may have got some clarity on this question but I still have some questions. I noticed that the guide "removing any references you've created to the resource/player to prevent memory leaks."
What does that actually look like in practice? I don't see any examples of "removing references" in the guide so I'm not quite sure what that would look like, and what to watch out for.
So I've done some digging around and I'm still confusing about things. Does running
player.stop() actually destroy the audio stream associated with the player? Because the stop() function claims too but I don't see any code that actually shows it killing the stream... Perhaps I am missing something?
So I did some more digging around and found that triggering the idle state is supposed to kill the resource. However, in the past, I've experienced issue with the "idle" event not firing, which is extremely concerning...
And in this function called "deleteAudioPlayer" I can't seem to see where it actually deleted the resource/stream?
If anyone can explain or knows better about this, would be greatly appreciated 🙏
Why is it designed this way thought? Wouldn't you expect running
player.stop() to immediately clear everything out instead of diverting it to the idle state to remove it?
How can I be confident that the idle state will work every time?
Additionally, in that case, what happens if I have one player that is playing, and then it gets interrupted by another player? Wouldn't that mean it never goes into idle?
Wdym 🤔
Oh nvm you are right
So if in the past, if I hadn't been calling player.stop() after audio stopped playing, am I right to assume that this could have been causing a memory leak?
Play a new resource on a new player would be the one. Although, I am running joinVoiceChannel() each time, but its my understanding that if a connection already exists, if I call that function, it just uses the existing connection, correct?
And I think what I was hinting at here, is that it doesn't destroy the stream or resource directly, hence making it susceptible to memory leaks with garbage collection and other references as you previously mentioned.
Taking a step back, how would I even use player.stop() if I wanted to? player.play() is not async which means I can't await it in the sense that I wait for the audio to finish playing. So if I called player.stop() after player.play() it wouldn't play the audio in the first place... Am I just meant not to use player.stop() in this case and fully rely on the idle state after the audio finishes playing?
I should also specify, that the way I use audio resources may be kind of different than the typical music player, as I'm not using it for that use case. A new unique audio resource is created when a user runs a command. And at the bottom of the command function, I'm listening to events relating to the player (playing, idle, error). I don't think this would cause any issues, but maybe it does as it relates to garbage collection as it is an event listener? Any insight into this is appreciated.
Also, would storing the audio resource in a let variable cause a problem as it related to garbage collection? Cause I do store it like let audio and then assign the stream to the audio variable later in the code.
I don't reference the "audio" let variable inside of the event listeners if that is what you mean
If that isn't what you mean, lmk
Could referencing the "player" variable in a function but not passing "player" into the function be the problem?
i.e.
Oooo, I may have just found my issue then 👀
For whatever reason, I wasn't passing player or audio into that function before this
Well if this solves my memory leak problem, massive thanks to you 🙏
And irrespective of if it fixes it or not, thanks for taking the time to help out :)
Will hopefully report back if I notice a major memory improvement in production 👍