Any chances of a dependency bump?
This is just an issue to raise awareness: Quote from @aleksrutins: "It seems like librespot has fixed this issue upstream - any chance of a dependency bump?" Thank you. https://github.com/xou816/spot/issues/728#issuecomment-2351729051
This is just an issue to raise awareness: Quote from @aleksrutins: "It seems like librespot has fixed this issue upstream - any chance of a dependency bump?" Thank you. #728 (comment)
Not to speak for the maintainers here, but I think it is being held up by upcoming librespot 0.5 release. The issue has been fixed but new version has not been released. See https://github.com/librespot-org/librespot/issues/1279#issuecomment-2332543048
You can see that in cargo.toml
[dependencies.librespot]
version = "0.4.2"
features = ["alsa-backend", "pulseaudio-backend", "gstreamer-backend"]
that stable (0.4.2 was released Jul 29, 2022) version from rust packages is being used, right now it would require to change pipeline to build librespot from scratch instead of using the package, if I am not mistaken.
A couple days ago, I tried building Spot with a freshly compiled version of librespot from the GitHub to see how much work would need to be done to get it working again.
error[E0432]: unresolved import `librespot::core::keymaster`
--> src/player/player.rs:7:5
|
7 | use librespot::core::keymaster;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `keymaster` in the root
Somewhat unsurprisingly, there appears to have been some breaking API changes with the transition from password to uauth. As I'm not familiar with the librespot API, I backed out there. I imagine that Spot will need to adjust to the new API and replace the password sign-in window with an uauth verification window. Looks like it won't be a trivial change.
Version 0.5.0 of librespot was just released, it has quite a lot of changes, see https://github.com/librespot-org/librespot/releases/tag/v0.5.0
I've made a start on this here: https://github.com/xou816/spot/compare/development...stevenleadbeater:spot:development I've just abused the login page on spot for now and hijacked it. There are 2 issues so far;
- The oauth url is println'd in the librespot code so I have to copy and past it into a browser, it appears to work, if I approve it and close the tab spot logs in and can see my albums and saved songs
- No music will actually play, I get this error:
[2024-10-26T21:03:12Z ERROR librespot_playback::player] Unable to load audio item: Error { kind: Unavailable, error: NonPlayable } [2024-10-26T21:03:12Z ERROR librespot_playback::player] Skipping to next track, unable to load track <SpotifyId("spotify:unknown:1iI5J72TQxYdQkKnkRwWCn")>: ()
I will try and do more with this, we need a login with spotify button so I can restore the original login behaviour and I need to debug the tracks not playing. First pass is probably to try and play tracks from the terminal using librespot directly. If that works then it's a case of trying to figure out what is different between those calls and ours in spot
Looks like tracks not playing is because we have to set the item_type manually on the SpotifyIds, see line32 in this librespot example (https://github.com/librespot-org/librespot/blob/d8d9ec73350b1a73f0433a6499d7289c6176c727/examples/play.rs#L32). I figured it out running librespot on the terminal and using the official app to play a song on librespot as a target device thingy, noticed the log showed: 2024-10-27T17:50:38Z INFO librespot_playback::player] Loading <Well Well Well> with Spotify URI <spotify:track:1iI5J72TQxYdQkKnkRwWCn> vs my failing unable to load track <SpotifyId("spotify:unknown:1iI5J72TQxYdQkKnkRwWCn")> unknown is the item_type. backfilling it worked and seems to be what the librespot example shows too
@xou816 @Diegovsky @knokelmaat please advise what to do with this? Do you want the login button for username / password? do you want just oauth2? I will have to sort out the issues with librespot println'ing the auth url and open it in the default browser. What do you want me to do to get this in a MR ready state?