mirror of
https://github.com/JakeStanger/mpd-discord-rpc.git
synced 2026-07-11 05:15:29 +01:00
[GH-ISSUE #110] Updates to discord stop if you skip songs too quickly #1626
Labels
No labels
bug
enhancement
help wanted
package
pull-request
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/mpd-discord-rpc#1626
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Kusoneko on GitHub (Feb 26, 2024).
Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/110
Hi,
I'm not sure how else to describe it but from my current usage, I have a hotkey setup to skip a song if I don't want to listen to it and go to the next in the playlist, and the currently playing song automatically appears in the top status bar of my screen. If I use that hotkey without giving the song a chance to play for maybe 5-10 seconds or so, I'm basically rolling a dice on whether discord will stop getting updates or not, and when I lose the dice roll, the music stays stuck on whatever song it was on when it broke, which creates a weird case where sometimes I learn way later that according to discord I've been listening to this one song for like 3 days or something. Hopefully it can be reproduced and fixed, it's not really a major bug but it is annoying to have to run
systemctl --user restart mpd-discord-rpcevery time it does this or to be forced to let a song that I don't want to hear play at that point in time.Pkg info below, not sure about how to give system info or if that'd even help.
@JakeStanger commented on GitHub (Feb 27, 2024):
Thanks for reporting, I'll try and look into this in the next few days
@JakeStanger commented on GitHub (Mar 3, 2024):
I've not been able to replicate this myself. Can you try starting directly with debug logging please, by running
RUST_LOG=debug mpd-discord-rpc, reproduce the issue, and send the log output? I'll have a look through the logs and see if I can deduce what's happening.@Kusoneko commented on GitHub (Mar 3, 2024):
I easily reproduced it with the debug logging on, I can't quite understand what's happening in the log however, but simply spamming my "next song" button about 10-20 times in a row definitely in less than a few seconds definitely made it happen again.
I used the command:
RUST_LOG=debug mpd-discord-rpc > mdr.log 2>&1to ensure everything was caught in the log file attached below:mdr.log
EDIT: Actually after putting it through
cat mdr.log | lesswhich somehow properly parses the log's terminal codes, which bat (currently aliased to cat) didn't for some reason, it seems to endlessly send command idle at some point and nothing else despite stuff happening, it never moves on to noidle or status or currentsong, it just sticks to idle.@JakeStanger commented on GitHub (Mar 14, 2024):
Sorry for the delay in getting back to you. I've tried to replicate this a few times still and haven't gotten anywhere. Sometimes if I push it, it appears to get stuck for 5-10 seconds, but then Discord catches up without an issue.
The log unfortunately doesn't give too much away. It just shows a 12 second window after the last update where the MPD event client is idling.
How are you connecting to MPD? Is it just a local server, or is it remote?
@JetpackJackson commented on GitHub (Mar 23, 2024):
I'm having the same issue, and can easily reproduce it as well. Here's my log:
mdr.log After activating this bug by spamming my "next" hotkey, if I pause the music, it doesn't force an update or anything.
@JetpackJackson commented on GitHub (Mar 23, 2024):
https://github.com/JakeStanger/mpd-discord-rpc/assets/88674707/096cad3b-dab2-40e1-8952-14dedb4054de
I caught the bug on video, if that helps.
@JakeStanger commented on GitHub (Mar 29, 2024):
Thanks for your patience on this one. I was finally able to replicate it today using a long playlist and the following loop:
There seemed to be a few issues with race conditions or buffers filling. I have just updated the underlying library and pushed a couple of updates onto master here that should sort it.
If you can give them a go and let me know if it seems to be sorted, that'd be hugely appreciated.
@JetpackJackson commented on GitHub (Mar 29, 2024):
I updated and tested it out with your script but I'm unfortunately still seeing the issue. What else can I do to help debug? I now have a feeling it might be something on my end with my setup as well. (side note: I'm going to be busy the rest of today due to an exam but I can continue to help out tomorrow if needed). I've attached another video of me testing the script.
https://github.com/JakeStanger/mpd-discord-rpc/assets/88674707/f9d92bf2-2a6a-4d8a-9d92-dfe4b3cb5056
@JakeStanger commented on GitHub (Mar 30, 2024):
Darn okay, really hoped I'd caught it. Could you repro with the following please:
RUST_LOG=tracesetThat will at least confirm if you're seeing what I was seeing.
@JetpackJackson commented on GitHub (Mar 30, 2024):
Alright, I'll try that. I installed the package from the AUR (
mpc-discord-rpc-git), how should I get the commit hash from that? Or would you prefer that I instead build from source this time to be sure?@JakeStanger commented on GitHub (Mar 30, 2024):
Building from source is more reliable as some AUR helpers can be a bit funny about
-gitpackages and may not update them. You can check with the AUR usingpacman -Q mpd-discord-rpc-gitthough - this will return the short commit hash.If it doesn't look like 205a7c1 then you're behind.
@JetpackJackson commented on GitHub (Mar 30, 2024):
I got
mpd-discord-rpc-git 1.7.2.r10.g205a7c1-1, but I'll still test out the build from source just to be safe.@JetpackJackson commented on GitHub (Mar 30, 2024):
file.log
Here's the log after running
cargo install mpd-discord-rpcand then running mpd-discord-rpc under the trace along with the loop script. It seemed to work this time in that it didn't require a restart! Is it possibly an issue with the AUR package in that case?@JakeStanger commented on GitHub (Apr 6, 2024):
Here's me reading the logs trying to work out why it looks like it's working fine, without reading this part of your message...
The -git AUR package will follow the latest commits, whereas
cargo installuses the latest tagged release. The weird thing is not much has changed between those except some package updates that should be unrelated, and the fixes I put in place last week.I'd suggest re-trying the AUR package from a clean build, and seeing if it persists then. If it does, it might be time to break out
git bisectand figure out exactly where it went wrong.@JetpackJackson commented on GitHub (Apr 6, 2024):
Alright! I'll try that in a bit and let you know how it goes.
@JetpackJackson commented on GitHub (Apr 6, 2024):
Alright, the issue persists with the AUR -git package. Sorry it took me so long to get back to you.
@fxzzi commented on GitHub (Apr 2, 2025):
Can confirm I am also having this issue. Sometimes the status just doesn't update correctly on Discord. Either it sticks on the same song even after I've paused or went onto a different song, or the status does update but for some reason on a completely different song.
the song playing is "resurrections", but discord activity shows "awake"
when no music is playing, it says I'm listening to "prologue" and the timer on it continues to go up indefinitely.
@fxzzi commented on GitHub (Apr 8, 2025):
possibly related, this is through vesktop using arRPC
seems like mpd-discord-rpc just keeps continuously creating new connections the rpc, you can see every single one got closed when I stopped the mpd-discord-rpc process.
@42willow commented on GitHub (Apr 9, 2025):
I'm not sure how the internals of this works, but my guess is that mpd-discord-rpc stops sending RPC info to discord when a song isn't playing - and discord continues to display it and increment the counter as it has not received a signal that the song has finished? Maybe this could be fixed by sending a signal to discord every ten seconds if there is nothing playing.
Of course, I could be completely wrong as I have not looked at the code and don't know how discord handles this.
Here are some screenshots
version:
1.8.0(song is paused)
Before
After quitting and reopening discord
@fxzzi commented on GitHub (Apr 24, 2025):
i can confirm the behaviour you experience when mpd is paused. for some reason discord continues to think its playing. maybe mdr isn't sending correct signals as you suggested?
@ashprice commented on GitHub (May 11, 2025):
I also have these issues - skipping songs causing changes in playback to not be registered, and paused songs continuing with an incrementing timer. Sometimes upon playing after a period of not playing music (where I was playing it before, say, some hours ago, and it was working as desired for at least some span of that previous time), it reports a song that was listened to much earlier than the most recent playback (not the most recent song, and not the currently playing song). I also use vesktop as my client, if it's relevant.
TThe reproducibility of these seems quite variable. If I stop the systemd user service, and start it again, I usually cannot reproduce any of them on demand. It's always that first instance after booting+login where it is worst; I wonder if it has something to do with issue #204 . I also wonder if brief network interruptions aren't playing a role: I don't know if the vesktop client is listening for RPC input during those. I will try to capture some relevant log/strace output over the next few days.
If I understand the source, a signal is sent to discord if MPD sends a signal that no song is playing on the event change:
So it's not just that no output is sent; it is explicitly cleared. Re-sending that signal periodically seems like it would address it, but it doesn't really answer why it happens. I don't know if the fact that sometimes a completely different song than the previous one or the one that is playing is some kind of clue here, or if it's rather just a symptom and that is clutching at straws.
@ashprice commented on GitHub (May 19, 2025):
I apologize for the delay. Had trouble reproducing some of these at times when I had spare time to capture and so on.
Here is some output from the case where the RPC in discord stops updating, but then you pause or skip and it then starts displaying output for the previous song. Sadly, I did not get the output for the actual song displayed throughout this period (a Jeff Buckley song) so all of these messages were sent without discord's RPC updating - I can't figure out how to redirect rust's env logger to a file, and we maxed out my terminal's 100,000 line scrollback, so I'll need to increase that for future tests...
Anyway, all of this was without Discord updating:
And then we pause it, and it shows the song that has just been paused:
A little while later, it correctly cleared RPC, about a minute after pausing the song. I didn't get this output, was too keen to kill the process, grab the previous output...
I am not really seeing anything obvious at all that would explain the behaviour in this output. I'll try to get some more, but I am thinking that they will likely prove unilluminating.
@JakeStanger commented on GitHub (Jun 22, 2025):
Just to break the radio silence on my end, I have noticed the issues with pausing too and I am looking into it. I'm struggling to reproduce it now though...
Thanks everybody for the extra info in this thread.
@emersonrp commented on GitHub (Jul 23, 2025):
FWIW, I was just tinkering with this a little, and I seem to be able to reproduce some pausing badness somewhat regularly, specifically by pausing mpd within the very first seconds of a new song.
I'm guessing some sort of race condition-ish thing happens while it's getting ready to update discord with the new song, and the pause command happens during that process?
In any case, if the pause happens immediately upon song change, occasionally the status will continue to count up "elapsed time" on the previous song. If song skipping happens at this point, it's possibly in that state where it will keep updating discord with an earlier song instead of new ones.
I realize that's not a 100% recipe, but hopefully the "pause immediately after song change" clue will be helpful in tracking down what's going on.
@chocoblocko9 commented on GitHub (Dec 6, 2025):
To chip in, I've been using this on NixOS with hyprland, and as far as I can tell, I only get issues if I auto start it on boot. If I put "exec-once = mpd-discord-rpc" in my hyprland config (which starts software when hyprland starts) OR I start the home-manager systemd service for NixOS, I get all of the issues mentioned in the thread (pausing not updating, songs getting stuck etc).
However, if I just start it after I boot from the command line or whatever it works perfectly, pausing clears the status, songs don't get stuck weirdly, status updates quicker, so yeah idk what's going on with that