mirror of
https://github.com/JakeStanger/mpd-discord-rpc.git
synced 2026-07-11 23:15:28 +01:00
[GH-ISSUE #105] RPC library error: channel to be open full(..) #561
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#561
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 @ashprice on GitHub (Feb 2, 2024).
Original GitHub issue: https://github.com/JakeStanger/mpd-discord-rpc/issues/105
This package was working fine - it's pretty cool, thanks! - until very recently, where it just... stopped. Not sure if it's a discord update, or something else.
systemctl --user status mpd-discord-rpc output:
On Arch linux 6.7.3-arch1-1, using Discord Stable 263172 (f95e991), not sure if any additional RPC package is relevant given none are listed as dependencies, but libtirpc is 1.3.4-1, just in case.
Not sure how to troubleshoot, to be honest. Running
mpd-discord-rpcwith the systemctl process stopped says that it connects to discord fine:And my firewall should be set up so as to allow discord to connect.
Restarting the systemctl process after killing both that from before and then killing the one ran in the terminal yields this systemctl output:
But still no cigar in the discord client.
Here is my config.toml:
Any advice on troubleshooting is gratefully received, and thank you for making a neat app!
@JakeStanger commented on GitHub (Feb 3, 2024):
Thanks for the detailed report. This is a strange one, I'm not sure what'd cause that from the above.
If you run with
RUST_LOG=trace mpd-discord-rpcyou should get a whole load of extra log output (your discord username will be in there near the beginning FYI). Could you retry with that and provide the full logs please, and hopefully that'll reveal something?@ashprice commented on GitHub (Feb 3, 2024):
Hmm. Today it is working. My guess is that it is something to do with multiple instances in some sense - my guess is that that error is it trying to connect to something, and finding it already in use? So maybe the process didn't terminate properly or fully for some reason.
This is just a guess, though, I don't really have much to support it...
I also sometimes have an issue where the track doesn't refresh, such that if I am listening to an album or playlist, my discord activity will show an 'activity' row on my profile for each previously played song, rather than only the currently playing song. I wonder if this is related.
I don't think sharing the log of the working instance will help, at least I don't see anything indicative of an error in there.
I will play around to try and reproduce either issue and get back to you.
@ashprice commented on GitHub (Feb 3, 2024):
Actually, I do have one update. I don't know if this is the cause of the previous issue, as I cannot reproduce the systemctl output at all. But anyway, this is a silly one - you sensibly enforce a 120 character limit, and if it is longer the activity won't display. However, you are more sensible than some artists, perhaps. From my library for example, I have the Fiona Apple album:
Now, I don't know if it's better not to add support for such rare albums - I assume it is like that for security, but I don't know much about such topics - but I'll note that you have to restart the process to get the rich present output working again. Here is the log:
Here I played a song from this album, and then tried skipping to a track by a different artist and in an album with a saner title length. Here I tried it again with a fresh process (this is the output from hitting 'skip' onwards, so misses the aforegoing error):
I don't know if this should be intended handling - I'd think one would expect the process to terminate and throw up an error or to go back to regular functionality (and maybe giving a warning).
@ashprice commented on GitHub (Feb 4, 2024):
Not a very helpful update, but I had the multiple track issue today, using the systemd daemon. Stopping, running from the terminal, and/or restarting with systemctl caused the issue to go away. The journalctl output is pretty uninformative:
I have edited the systemctl daemon to run with the rust debug output, so hopefully I'll catch something about either issue soon.
Edit: Nevermind, it doesn't like that. I'll try running from the terminal henceforth and catching it that way...
@JakeStanger commented on GitHub (Feb 4, 2024):
Sometimes Discord can be a bit funny about multiple RPC clients connected at once, but it should work. There's nothing that explicitly shouldn't, at least.
I would expect errors to appear if this was from the client. Probably more likely this is Discord playing up (this more than likely could be related to multiple clients running, especially if one goes wonky).
Not me :p This looks like a hard limit on Discord's side, and it "crashes" as a result of the error response from the RPC server. I should be able to clamp input to just show
...after a max length to resolve that at least though.Apart from the length error, the logs don't show a lot that'd suggest anything out of the ordinary unfortunately. It's possible if you were hitting that, and then the client continued running for long enough, you'd fill the channel and hit the error in the initial post. I'll patch that and get a release out, and we can see how it goes from there I guess.
@JakeStanger commented on GitHub (Feb 4, 2024):
If you're able to try that PR, let me know how that works for you
@JakeStanger commented on GitHub (Mar 3, 2024):
Hey @ashprice, have you had a chance to try the above?
@ashprice commented on GitHub (Mar 10, 2024):
Sorry for disappearing for a while.
The main issue: I can confirm this PR works. I haven't encountered any issues with it. Will let you know if I do. Thank you for getting a fix so fast.
For the multiple-output thing, probably I need to try to pin it down one more time, and make a new issue, but there's a chance there's something in my configuration that I cannot find that leads to multiple instances launching when specifically it is enabled as a systemd daemon - I get the issue only when systemd starts the process automatically; if I restart it, no issue, if I launch it manually, no issue.
@JakeStanger commented on GitHub (Mar 15, 2024):
Thanks for confirming. In that case I'll merge the fix and close this. If you manage to find anything more on the duplicate issue feel free to open another issue ofc.