MusicBot
MusicBot copied to clipboard
[Bug Report] Doesn't seem to play anything
Bug Description
The bot doesn't seem to play anything. When I call the bot in discord, it would reply "Added (song title) to begin playing". But there are no audio and if I check nowplaying, it would say there must be music playing to use that. Checked the console and this is all it shows: [16:23:25] [INFO] [JMusicBot]: Loaded config from D:\musicbot\config.txt [16:23:25] [INFO] [JDA]: Login Successful! [16:23:25] [INFO] [WebSocketClient]: Connected to WebSocket [16:23:25] [INFO] [JDA]: Finished Loading! [16:23:33] [INFO] [YoutubeAccessTokenTracker]: Updating YouTube visitor id (current is null). [16:23:33] [INFO] [YoutubeAccessTokenTracker]: Updating YouTube visitor id succeeded, new one is CgtqSjY4aVdscmx1RSjF0rGwBjIKCgJVUxIEGgAgUToKIPi3le_RqJqGZg%3D%3D, next update will be after 600 seconds.
Steps to Reproduce
- Launch the bot
- Use the play command in discord
- No audio despite the bot responding
Expected Result
The bot is "half alive" it will look like it works but it won't do anything(no audio)
Debug Output
System Properties:
java.version = 11.0.21
java.vm.name = Java HotSpot(TM) 64-Bit Server VM
java.vm.specification.version = 11
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 11.0.21+9-LTS-193
java.specification.version = 11
os.arch = amd64
os.name = Windows 10
JMusicBot Information:
Version = 0.4.0
Owner = ( Removed by me, but it shows my discord ID)
Prefix = ?
AltPrefix = null
MaxSeconds = 0
NPImages = false
SongInStatus = true
StayInChannel = true
UseEval = false
UpdateAlerts = true
Dependency Information:
JDA Version = 4.4.1_353
JDA-Utilities Version = 3.0.5
Lavaplayer Version = 727959e9f621fc457b3a5adafcfffb55fdeaa538-SNAPSHOT
Runtime Information:
Total Memory = 254
Used Memory = 143
Discord Information:
ID = 901305000062484520
Guilds = 3
Users = 3
Additional Info
No response
Checklist
- [X] I have looked for information about this within the documentation
- [X] I have searched for similar issues on the issues page
- [X] I am running the latest version of the bot:
Can also confirm.
This happens with the latest version 0.4.0.
However you can bypass the issue by using the previous version JMusicBot-0.3.9
Can confirm aswell
same
Same situation here, after downgrading to version 0.3.9 everything works fine.
Same URL:
on 0.4.0 - 🚫 Error loading: Video returned by YouTube isn't what was requested on 0.3.9 - works perfectly fine
Same here. Downgrading to 0.3.9 works.
can confirm, issue is with 0.4.0, downgrade worked
Same issue here. Waiting for a fix before updating.
same issue using 0.4.0 downgrading to 0.3.9 works well
Also experiencing this. java 17.0.6 2023-01-17 LTS
Downgrading fixed for me as well. Downgrading.
Been getting a lot of "Error loading: Video returned by YouTube isn't what was requested " as of late. Nothing in the logs indicates what the real error is, let alone what the output was.
Is there a way to drop it into debug logging to see those outputs?
I am also having this issue, although I have found that it isn't a global won't play anything issue but only with youtube. I tested both Soundcloud and twitch stream audios and those worked just fine.
Same and I can't downgrade on my server because its running as service and I can't be there to skip the "new update" everytime it starts. Hope it gets fixed soon
Youtube will not playback on 0.4.0 with macOS 14.4.1, Soundcloud still works with 0.4.0. I wonder if it is related to this warning from the terminal when running the jar file (MacOS 14.4.1 Sonoma latest release):
WARNING: Secure coding is automatically enabled for restorable state! However, not on all supported macOS versions of this application. Opt-in to secure coding explicitly by implementing NSApplicationDelegate.applicationSupportsSecureRestorableState:.
Likely not as that warning is still present on 0.3.9.
I can confirm that 0.3.9 still works and can playback YouTube music, so I think this is likely something to do with the latest MacOS release and 0.4.0 only.
Can confirm same issue, downgrading to 0.3.9 fixes the issue
Downgraded and now the bot sends me a discord PM frequently telling me about a new version
Downgraded and now the bot sends me a discord PM frequently telling me about a new version
Yo can change that in the config file, just read the manual.
Downgraded and now the bot sends me a discord PM frequently telling me about a new version
add updatealerts=false to your config.txt file :)
Will this be resolved in 4.1.0?
I can confirm, for me doesn't work on Ubuntu (haven't tested on Windows)
It seems to be an issue with how version 0.4.0 handles ingest from YouTube, as other ingest sources still work. Id imagine version 0.4.1 would include a rollback/fix to YouTube as the previous version of 0.3.9 works well.
It seems to be an issue with how version 0.4.0 handles ingest from YouTube, as other ingest sources still work. Id imagine version 0.4.1 would include a rollback/fix to YouTube as the previous version of 0.3.9 works well.
A rollback will lead to the 403 issues that plagued the extremely-outdated lavaplayer build in 0.3.9; we're going to wait for a proper fix for this from the new lavaplayer fork
There's an open pull request at https://github.com/lavalink-devs/lavaplayer/pull/88 that fixes this issue. I've made a build of JMusicBot on my fork that includes the changes of that pull request. You're welcome to try that version out & use it as a temporary stop-gap solution until 0.4.1 comes out.
The release is on my fork & is provided as-is. No support is provided here. Do not report issues of my fork on here.
just to add my 2 cents, I got called in by a friend to help troubleshoot his music bot on 0.4.0 version after he upgraded on Windows 10. Tried lots of things, but had to downgrade to get it to work. One difference between version 0.4.0 and 0.3.9 that I noticed is that when the 0.4.0 music bot joined the voice channel, it had the "deafened" status symbol. We could find no permission concerning this in the settings file or on Discord. I don't know if it is related to us not hearing the audio.
just to add my 2 cents, I got called in by a friend to help troubleshoot his music bot on 0.4.0 version after he upgraded on Windows 10. Tried lots of things, but had to downgrade to get it to work. One difference between version 0.4.0 and 0.3.9 that I noticed is that when the 0.4.0 music bot joined the voice channel, it had the "deafened" status symbol. We could find no permission concerning this in the settings file or on Discord. I don't know if it is related to us not hearing the audio.
this has nothing to do with what you hear, its a privacy quality of life feature to show that the bot is not listening to you and potentially recording private data
just to add my 2 cents, I got called in by a friend to help troubleshoot his music bot on 0.4.0 version after he upgraded on Windows 10. Tried lots of things, but had to downgrade to get it to work. One difference between version 0.4.0 and 0.3.9 that I noticed is that when the 0.4.0 music bot joined the voice channel, it had the "deafened" status symbol. We could find no permission concerning this in the settings file or on Discord. I don't know if it is related to us not hearing the audio.
this has nothing to do with what you hear, its a privacy quality of life feature to show that the bot is not listening to you and potentially recording private data
Actually, the "deafened" status is purely visual and doesn't prevent a bot from recording you. Only the "server deafened" status actually prevents a bot from receiving audio.
looks like lavalink-devs spun off youtube support into a separate project under https://github.com/lavalink-devs/youtube-source and will not be updating the base lavaplayer
source: https://github.com/lavalink-devs/lavaplayer/issues/97#issuecomment-2067810065
Having the same issue, hopefully fixed soon! Rollback to 3.9.0 for now.
Must be the deafened state that is the problem here. It prevents a user from sending audio, so the same thing might be happening with the bot.
Must be the deafened state that is the problem here. It prevents a user from sending audio, so the same thing might be happening with the bot.
No. Deafening the bot is for audio only. The bot doesn't need to hear you speak audibly. Theoretically saves bandwidth because no audio is transmitted to the bot.
Must be the deafened state that is the problem here. It prevents a user from sending audio, so the same thing might be happening with the bot.
No. Deafening the bot is for audio only. The bot doesn't need to hear you speak audibly. Theoretically saves bandwidth because no audio is transmitted to the bot.
While deafening is unrelated to this issue, deafening doesn't save any bandwidth because the bot still receives audio when deafened. Only server-deafening actually saves bandwidth.