MPRIS OpenUri fails due to incorrect device_name

[timlag1305]

Description When I run dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotifyd /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.OpenUri "string:https://open.spotify.com/track/5OmIZhbwxGD1BwozQJe0t8?si=0pSNgfWySnqWPp8pf5MWTQ", spotifyd logs show that it receives and handles the OpenUri call. However, when I debug, I see that device_name of the current device is different than what the Spotify web API returns. Where Spotify web API returns an @ character, the local spotifyd config encodes that as %40d (e.g. Spotifyd@hostname vs Spotifyd%40dhostname). This prevents any device from being selected on the following line: https://github.com/Spotifyd/spotifyd/blob/133a1199f80c7c22f29a45226db3bb856b106a5b/src/dbus_mpris.rs#L340

This is especially problematic because the default device_name has an @.

To Reproduce

1. Make spotifyd player the active device
2. Run command dbus-send --print-reply --dest=org.mpris.MediaPlayer2.spotifyd /org/mpris/MediaPlayer2 org.mpris.MediaPlayer2.Player.OpenUri "string:https://open.spotify.com/track/5OmIZhbwxGD1BwozQJe0t8?si=0pSNgfWySnqWPp8pf5MWTQ"
3. Notice the song doesn't change/start playing

Expected behavior Song should play after that dbus-send command.

Logs The entire log was way too long to include so I just included a snippet where you can see the MPRIS call.

Click to show logs

``` event Readable Token(33554437) loop process - 1 events, 0.000s event Readable Token(33554437) D-Bus i/o poll ready: 59 is Ready(Readable) D-Bus i/o unix ready: 59 is Readable | Aio loop process - 1 events, 0.000s event Readable Token(33554437) loop process - 1 events, 0.000s handle_msgs: (MethodCall, Some("/org/mpris/MediaPlayer2"), Some("org.mpris.MediaPlayer2.Player"), Some("OpenUri")) loop poll - 29.283066ms loop time - Instant { tv_sec: 5545, tv_nsec: 23818785 } loop process, 11.562µs Polling message stream msgstream found Ok(Ready(Some((MethodCall, Some("/org/mpris/MediaPlayer2"), Some("org.mpris.MediaPlayer2.Player"), Some("OpenUri"))))) Polling message stream msgstream found Ok(NotReady) D-Bus i/o poll ready: 59 is Ready(Readable) D-Bus i/o unix ready: 59 is Readable | Aio scheduling Read for: 5 loop poll - 71.173µs loop time - Instant { tv_sec: 5545, tv_nsec: 24148965 } loop process, 9.779µs take? ("https", api.spotify.com): expiration = Some(90s) reuse idle connection for ("https", api.spotify.com) Client::encode method=GET, body=None flushed 398 bytes flushed({role=client}): State { reading: Init, writing: KeepAlive, keep_alive: Busy } event Readable | Writable Token(29360132) loop process - 1 events, 0.000s attempting to decode a frame frame decoded from buffer attempting to decode a frame frame decoded from buffer ```

Compilation flags

• [x] dbus_mpris
• [x] dbus_keyring
• [ ] alsa_backend
• [ ] portaudio_backend
• [x] pulseaudio_backend
• [x] rodio_backend

Versions (please complete the following information):

• OS: Linux arch 5.9.2
• Spotifyd: 0.2.24
• cargo: 1.42.0

I think it's really only possible to see the error when debugging. I might be able to create a PR to fix this but I don't really know rust. I'm sure someone that knows rust could fix this easily.

[xtenduke]

Done a bit of debugging... I resolved the issue with the @ -> %40 percent encoding easily enough, but now getting 400s from the api when giving URI as https://open.spotify.com.... when passing in "string:spotify:track:225xvV8r1yKMHErSWivnow" works fine, but I think this is a separate issue...

[xtenduke]

Ignore previous, wildly incorrect. Playback fails as API returns 400 because the track URI is incorrect.

Playback/context URIs should be specified in format "spotify:track:1301WleyT98MSxVHPZCA6M"

https://developer.spotify.com/documentation/web-api/reference/player/start-a-users-playback/

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[eladyn]

I think that at least with #1079, this issue should be resolved. @timlag1305, feel free to reopen, if this isn't the case.