end event weirdness

[fatchan]

So for a while, my skip command would just end the current track by using .stop() on the player, causing the end event to fire wher I had code to play the next track. At some point I thought:

shouldn't I just .play() with a new track?

I can. But, this causes issues that I can't seem to figure out.

So there are 2 scenarios:

1. (my old way of skipping or going to the next song for any reason)

• play() a track - it plays.
• end event works, inside the event i have code to go to the next song
• if somebody skips, I just stop() the player, and the end event fires, again playing the next song

2. (new way where I "replace" tracks)

• play() a track - it plays.
• end event works, inside the event i have code to go to the next song
• if somebody skips, instead of stopping the player, which forces the end event to fire, I just play() the next track.
• The track will play, BUT the end event will not fire for this track.

Also strange:
in the second scenario, the first and only the first track that i .play() while another is playing (rather than stopping to force the end event) will cause the end event to fire twice (yes, it is .once()). 2 identical data with "REPLACED" reason.
Calling play() while a song is playing subsequent times, the end event will fire with the "REPLACED" reason once as expected, however the "FINISHED" end event will never fire for any of these.

---

Edit: I think I figured out why this happens:
When playing the next track, the player starts and registers all the listeners (which are .once) before the end event with reason "REPLACED" occurs. Therefore, when the "REPLACED" event fires, both the .once listener stops listening to the end of the track and never sees the "FINISHED" event.

My sketchy solution (for now) was to make it a .on and remove all listeners imemdiately before doing .play(), then re-registering them afterwards as normal. This prevents the situation above.