Closed freyacodes closed 7 years ago
I am also having this issue with the latest builds of JDA/Lavaplayer at the moment. Users are reporting a 3x speed up in audio.
I too have this issue.
Do any of you use NAS. What build did you start seeing this occur?
I'm using NAS on build 193
On 16 May 2017 at 18:15, Austin Keener notifications@github.com wrote:
Do any of you use NAS. What build did you start seeing this occur?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/DV8FromTheWorld/JDA/issues/357#issuecomment-301834214, or mute the thread https://github.com/notifications/unsubscribe-auth/ACdoWU-4HTYLQWnffSt1BE-OzRaLAP25ks5r6cuxgaJpZM4NccVk .
Started on build 193 too. Removed NAS with no change in behaviour.
Some people reported to me that this is immediately after reconnecting with the close code 4003 which was fixed in build 194/195. Would you be able to reproduce this behaviour on the latest build 200?
I heard from one of my users that audio was sped up, though this time the bot is under heavy load. Running on 3.0.0_200
.
just received an audio sped up report on 3.1.0_204 without JDA-NAS
Just got a report of speeding up on JDA 3.1.0_204
with NAS.
All this doesn't contribute to finding the issue. I need more information on how the speed up is caused, how it behaves, how you fix it, how global the issues is (does it affect more than one guild?), etc.
Affects only one guild. The fix is to unregister the AudioSendHandler of the guild for everyone (and for all devs I've talked to) having this issue. You can sometimes replicate it by spamming open/close audio connection, but the issue is rather random. It behaves in intervals, at first it's 2x, and goes up and up the more time you leave it there.
Unregistering the AudioSendHandler would kill the AudioSendSystem, thus killing the one that we want to have (for normal sending) and killing any others that are ghosting. This, along with some information in the Discord channel basically confirm that there are ghost AudioConnections running that are siphoning audio information out of the AudioSendHandler.
Additionally, based on the fact that it has been stated that the problem can be generated due to quick succession of Open/Close or due to disconnect/reconnect, it leads me to believe that something in the recent change to make the connection system asynchronous has caused a racecondition. That, or AudioConnections are not being properly destroyed during those conditions.
Will continue my investigation. Thank you everyone for your continued investigation.
Got another report, guild Id is 270310054790430721 dump.txt
Please give the bug/audio-speedup branch a try. I believe the change in logic there will fix the issue.
I received a couple complaints that suggests that the fix is not working since I updated to the speedup branch.
@Frederikam run on 3.1.1
for now. If you get additional reports, let me know.
Currently running on 3.1.1_210 and still got reports of double speed audio.
Got 2 reports of it happening here too. Seems to happen less, but still happens, sadly.
Since you have gotten new reports I'll reopen this issue for further investigation.
https://mantaro.ratelimited.today/35aab1.jpg Yeah, I get up to 5 reports/day again. Ohh well.
If it's worth anything I never experience this.
"Register your AudioSendHandler: audioManager.setSendingHandler(myAudioSendHandler) You may only use one AudioSendHandler per Guild and not use the same instance on another Guild! Doing that will result in speedup due to multiple send threads pulling from the same instance!" Idk if this helps
src --> https://github.com/DV8FromTheWorld/JDA/wiki/4)-Making-a-Music-Bot
While that is true, that is not what is causing the problem here. At least it shouldn't be. Might not hurt to add an iterative check to make sure that it isn't registered somewhere else.
@ducc You're using _176 tho 🤔
Devs this is still a bug, we need a fix PLES
@Ritchie454 if you can tell us exactly how to fix it then please do, otherwise this does not contribute to fixing it. We are looking into this bug as you can see the issue is still open for that exact reason.
The issue seems to lay on LP example (https://github.com/sedmelluq/lavaplayer/blob/master/demo-jda/src/main/java/com/sedmelluq/discord/lavaplayer/demo/jda/GuildMusicManager.java#L32) on how SendHandlers are created. Every bot that doesn't use that, doesn't get the speedup.
Changing that to a variable and updating it in the constructor seems to fix it or at least the SpeedingTicketFactory isn't spilling a lot of things at me.
I found it because on a speedup guild I did .getSendHandler and music got faster, then faster, then faster every single time I ran it.
Basically seems that what @StijnSimons says it's kinda true, it creates multiple in very niche occations using what's in the example.
Weirdly, with the same code this didn't happen prior to 193.
(Seems to happen even if you don't set it, just getting the method in a sped up guild was enough to give more speedup somehow)
Nope. Still happens so I take back what I said.
Tho, it was interesting to see that making it speedup more everytime it was called.
Could you guys try out patch-speedup
using jitpack and report back?
This should be fixed as of e5f023d
😅 💦 😅 💦 thanks 😅 💦 for 😅 💦 the 😅 💦 fix 😅 💦 boys!!! 😅 💦 😅 💦
🎉
Still happens with version 1.3.7
I'm sorry, what? This issue is from 3 years ago and JDA is on major version 4 at this point.
Are you saying you're still using JDA Major version 1?
Might be referring to LavaPlayer 1.3.7 (though it's on 1.3.49) is my only guess.
I have been getting reports that sometimes audio is sped up significantly. This seems to be an issue with how JDA sends audio. My guess is that JDA is requesting two frames every 20ms as opposed to just one. This doesn't seem to be lag, as I was experiencing this on a bot with low network and CPU load.
Setting a new sending handler seems to temporarily fix this. It could possibly also be a lavaplayer issue as I am instantiating the player with the sending handler, but I doubt that.
Leaving a VoiceChannel or changing the server region has no effect on this.
@kodehawa is also experiencing this.