mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1435] PlayerEvent::ShuffleChanged and PlayerEvent::RepeatChanged not sent #647
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#647
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 @eladyn on GitHub (Jan 4, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1435
Description
When pressing the shuffle or repeat button, the state is properly updated but not propagated through the
PlayerEventchannel.Version
dev7003e98c1bHow to reproduce
librespot --onevent envLog
This is not a debug log, but I changed shuffle and repeat several times during this run, and that should trigger the onevent hook:
github.com/librespot-org/librespot@7003e98c1b/src/player_event_handler.rs (L225-L228)Host (what you are running
librespoton):Additional context
I'm not sure whether the various other errors in the log are intended currently, otherwise I could of course open bug reports for them as well. (In particular the
Too Many Requestsseems interesting, but also the unknown enum variantWIFI_BROADCAST_CHANGED.@photovoltex commented on GitHub (Jan 4, 2025):
Huh, good find. Seems like that part was overlooked. Just to clarify the behavior, it only doesn't notify when we (librespot) are in control, right?
The other errors:
The
WIFI_BROADCAST_CHANGEDis an known error that doesn't break anything. But we should probably handle or fix it. Didn't bother yet as it doesn't break anything.Too Many Requestsis a failure that happens when to many request updates are send. That should be sorta fixed/improved with this PR https://github.com/librespot-org/librespot/pull/1414@eladyn commented on GitHub (Jan 4, 2025):
Thanks for the reply!
I was looking through the code a bit and I think, the updates are only ever sent on activation of the session? So it wouldn't matter whether we cause or another client causes the update.
@photovoltex commented on GitHub (Jan 4, 2025):
Yeah seems like it. The previous calls where probably removed during the dealer rework and because they do not influence the overall connect handling it did run under the radar.
@eladyn commented on GitHub (Jan 4, 2025):
Makes sense. I could probably get around to creating a PR re-adding them by the end of next week or something, but if you or someone else is motivated, I would not mind either.
@photovoltex commented on GitHub (Jan 4, 2025):
Sounds good. You can check here (https://github.com/librespot-org/librespot/network) if anyone created a branch that sounds like the fix (I probably won't till some time passed).
@maraid commented on GitHub (Jan 16, 2025):
Hey! I just wanted to let you know my minor finding.
It does seem to break at least the sending of "session_connected" player events. You mentioned in https://github.com/librespot-org/librespot/issues/1419#issuecomment-2546675656 that it might be caused by an out-of-date model, but it does work on master which indicates me that it the issue might lie elsewhere. Unfortunately I'm not really a rust person, so fixing it myself might prove difficult.
@photovoltex commented on GitHub (Jan 16, 2025):
It works on
masteror the latest release version (aka 0.6) because it isn't send there as they still use mecury to receive the connect session infos. With0.6-dev, aka thedevbranch we finally got around to implementing the dealer (#1356) which gives use more infos about the connect session and additonally more commands to handle. We also recently updated the protobuf extract to an up to date state, but sadly they didn't fix the problem in regards to the missing enum variant yet.Anyhow this isn't the main issue at hand. So if you have any concerns about the warning/errors or want to fix them we should open a separate issue/PR for them :)
@radoslawg commented on GitHub (Jan 20, 2025):
I have noticed setting a repeat playlist in the client does not work, and some random songs are played after the playlist is finished. I cannot fully follow the discussion, but would this issue be responsible for that? Strangely shuffling seems to work (using
raspotify 0.46.1withlibrespot 0.6.0 383a6f6 (Built on 2025-01-17, Build ID: jkYzFN5D, Profile: release))@photovoltex commented on GitHub (Jan 20, 2025):
This issue is related to the
devversion. During the replaced of mercury with the dealer it seems we removed to much and by that this issue was created.What you are referring to, might be already fixed on the
devbranch But you should probably create a separate issue anyways on the matter, so that we can investigate the issue and check if it is resolved with the current version :)