Constant rejoin loop

[JulianGmp]

Bug Description

When trying to play music the bot will join the voice channel, immediately leave, then rejoin, leave... in an endless loop.

I noticed that this only occurs when I run the bot on my Linux server, after downloading the same files (jar file and config) to my windows machine it started working.

Steps to Reproduce

1. try a play command or use the search command (the effect will occur even before selecting a song).
2. enjoy the constant join and leave sounds

Expected Result

The bot to stay and start playing music

Debug Output

System Properties:
  java.version = 1.8.0_292
  java.vm.name = OpenJDK 64-Bit Server VM
  java.vm.specification.version = 1.8
  java.runtime.name = OpenJDK Runtime Environment
  java.runtime.version = 1.8.0_292-b10
  java.specification.version = 1.8
  os.arch = amd64
  os.name = Linux

JMusicBot Information:
  Version = 0.3.6
  Owner = 142310000977510400
  Prefix = @mention
  AltPrefix = _
  MaxSeconds = 0
  NPImages = false
  SongInStatus = true
  StayInChannel = false
  UseEval = false
  UpdateAlerts = true

Dependency Information:
  JDA Version = 4.3.0_324
  JDA-Utilities Version = 3.0.5
  Lavaplayer Version = 1.3.78

Runtime Information:
  Total Memory = 192
  Used Memory = 34

Discord Information:
  ID = 894670509403406366
  Guilds = 1
  Users = 4

Additional Info

The debug output on my windows machine

System Properties:
  java.version = 1.8.0_271
  java.vm.name = Java HotSpot(TM) 64-Bit Server VM
  java.vm.specification.version = 1.8
  java.runtime.name = Java(TM) SE Runtime Environment
  java.runtime.version = 1.8.0_271-b09
  java.specification.version = 1.8
  os.arch = amd64
  os.name = Windows 10

JMusicBot Information:
  Version = 0.3.6
  Owner = 142310000977510400
  Prefix = @mention
  AltPrefix = _
  MaxSeconds = 0
  NPImages = false
  SongInStatus = false
  StayInChannel = false
  UseEval = false
  UpdateAlerts = true

Dependency Information:
  JDA Version = 4.3.0_324
  JDA-Utilities Version = 3.0.5
  Lavaplayer Version = 1.3.78

Runtime Information:
  Total Memory = 195
  Used Memory = 45

Discord Information:
  ID = 894670509403406366
  Guilds = 1
  Users = 4

The log on the windows machine:

[21:57:50] [INFO] [Startup]: Loaded config from E:\Users\yeetus\Desktop\jmusicbot\config.txt
[21:57:51] [INFO] [JDA]: Login Successful!
[21:57:51] [INFO] [WebSocketClient]: Connected to WebSocket
[21:57:52] [INFO] [JDA]: Finished Loading!
[21:57:53] [INFO] [NativeLibraryLoader]: Native library libmpg123-0: loading with filter com.sedmelluq.discord.lavaplayer.natives.ConnectorNativeLibLoader$$Lambda$197/1986424356@2bb7b3d4
[21:57:53] [INFO] [NativeLibraryLoader]: Native library libmpg123-0: successfully loaded.
[21:57:53] [INFO] [NativeLibraryLoader]: Native library connector: loading with filter null
[21:57:53] [INFO] [NativeLibraryLoader]: Native library connector: successfully loaded.

The log on the linux machine:

$ java -Dnogui=true -jar ./JMusicBot-0.3.6.jar
[21:50:46] [INFO] [Startup]: Loaded config from /home/retard/jmusicbot/config.txt
[21:50:47] [INFO] [JDA]: Login Successful!
[21:50:47] [INFO] [WebSocketClient]: Connected to WebSocket
[21:50:47] [INFO] [JDA]: Finished Loading!
[21:51:02] [INFO] [NativeLibraryLoader]: Native library libmpg123-0: loading with filter com.sedmelluq.discord.lavaplayer.natives.ConnectorNativeLibLoader$$Lambda$174/2014819614@5f558a52
[21:51:02] [INFO] [NativeLibraryLoader]: Native library connector: loading with filter null
[21:51:02] [INFO] [NativeLibraryLoader]: Native library connector: successfully loaded.
^C[21:51:11] [INFO] [RateLimiter]: Waiting for 1 bucket(s) to finish. Average queue size of 0 requests

As a final question: could this be related to firewall settings on the linux machine? I have them set fairly strict but I'd expect no websocket connection to be opened at all in that case.

Checklist

• I have looked for information about this within the documentation
• I have searched for similar issues on the issues page
• I am running the latest version of the bot:

[MichailiK]

Voice connections use a WebSocket & UDP connection to *.discord.media (for example europe123.discord.media). Ensure that *.discord.media is whitelisted in your Firewall for both TCP (for the voice websocket) & UDP (for the actual voice data).

Note that the voice domain can change at any time. Firewalls generally have logging capabilities, so you can check which connections are being blocked & whitelist domains appropriately if you encounter issues.

[JulianGmp]

I tested this and yeah it's related to the firewall.
According to a tweet from the official discord account, discord uses a random tcp/443 for the websocket and a random udp port from 50000 to 65535.

I don't know why they use a random port, it sounds horrible to me and gives me FTP flashbacks.

Is there any way to make your music bot use a fixed port instead? I would much prefer opening only one port compared to 15 thousand.

Edit: also, I think logging an error message if this happens would be nice, though I'm unsure if that's possible with the libraries/APIs the project is using.

[MichailiK]

Discord determines the UDP port to use, so there is nothing we can do about it.

I believe that logging should be possible though.

[JulianGmp]

Discord determines the UDP port to use, so there is nothing we can do about it.

That's a let down, oh well.
But it works now, thank you for the quick help

[Meng-lab-hub]

I am using MacOS and facing the same particular problem. However, I am relatively new to this topic and don't know how to address this problem even after this answer. May I have a more step-by-step solution?

[Shana195]

ive been trying to fix this problem since today. i don't have much knowledge with this sort of things. do i just need to create a firewall outbound/inbound rule for the jar file?

[JulianGmp]

Yes, an out bound rule for UDP 50000-65535 should do the trick.
Now there are better solutions for random ports other then opening the entire range (nf_conntrack might be a solution). Maybe you could open the port only for a specific user and have a dedicated service user too.

If I do find a more elegant solution I'll post it here.