Updates to discord stop if you skip songs too quickly

[Kusoneko]

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-rpc every 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.

$ pacman -Qi mpd-discord-rpc-git
Name            : mpd-discord-rpc-git
Version         : v1.7.1.r91.g07a6a22-1
Description     : Displays your currently playing song / album / artist from MPD in Discord using Rich Presence.
Architecture    : x86_64
URL             : None
Licenses        : MIT
Groups          : None
Provides        : None
Depends On      : None
Optional Deps   : None
Required By     : None
Optional For    : None
Conflicts With  : None
Replaces        : None
Installed Size  : 6.40 MiB
Packager        : Kusoneko <[email protected]>
Build Date      : Sun 04 Feb 2024 04:45:35 AM EST
Install Date    : Sun 04 Feb 2024 04:46:18 AM EST
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : None

[JakeStanger]

Thanks for reporting, I'll try and look into this in the next few days

[JakeStanger]

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]

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>&1 to ensure everything was caught in the log file attached below:

mdr.log

EDIT: Actually after putting it through cat mdr.log | less which 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]

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]

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]

https://github.com/JakeStanger/mpd-discord-rpc/assets/88674707/096cad3b-dab2-40e1-8952-14dedb4054de

I caught the bug on video, if that helps.

[JakeStanger]

Thanks for your patience on this one. I was finally able to replicate it today using a long playlist and the following loop:

while [ $(mpc playlist | wc -l) -gt 1 ]; mpc next; end

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]

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]

Darn okay, really hoped I'd caught it. Could you repro with the following please:

• Log file with RUST_LOG=trace set
• The exact commit hash you built from (just to be sure)

That will at least confirm if you're seeing what I was seeing.

[JetpackJackson]

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]

Building from source is more reliable as some AUR helpers can be a bit funny about -git packages and may not update them. You can check with the AUR using pacman -Q mpd-discord-rpc-git though - this will return the short commit hash.

If it doesn't look like 205a7c1 then you're behind.

[JetpackJackson]

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]

file.log Here's the log after running cargo install mpd-discord-rpc and 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]

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?

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 install uses 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 bisect and figure out exactly where it went wrong.

[JetpackJackson]

Alright! I'll try that in a bit and let you know how it goes.

[JetpackJackson]

Alright, the issue persists with the AUR -git package. Sorry it took me so long to get back to you.