Closed nathan-sain closed 4 years ago
Hmm, to be honest, the initial metadata pipe was written to mimic the old spotify-connect-web
that I customised again for Volumio. There were limits to how deep we could sink hooks back then, whereas we can go much deeper with librespot
.
An artefact of this is that when the first session becomes active, but a song is not actively playing, there is indeed no metadata sent. Instead you should see kSpPlaybackNotifyBecameActive
and kSpDeviceActive
along with the token. It should be trivial to add the metadata as well to this, and handle it differently as needed for Volumio in our metadata parser.
Out of curiosity, could you share more details about your display script? I should have an old branch somewhere where with a simple web page that I baked in during the initial days of this daemon..
The issue I have is triggered by switching ongoing playback to Vollibrespot. In that case the in-progress track metadata isn't emitted. The token data structure is emitted just not any track metadata.
The output from the daemon looks like this:
[Vollibrespot] : Event: SessionActive { became_active_at: 1588752994978 }
[Vollibrespot] : SessionActive!
[Vollibrespot] : Event: PlaybackStarted { track_id: SpotifyId { id: 46225423555138098331153281827319338395, audio_type: Track } }
[Vollibrespot] : Event: GotToken { token: Token { access_token: "XXX", expires_in: 3600, token_type: "Bearer", scope: ["streaming", "user-read-playback-state", "user-modify-playback-state", "user-read-currently-playing", "user-read-private"] } }
[Vollibrespot] : Loading <Moonshine> with Spotify URI <spotify:track:13CxBgSBcYey7h2SQXe9xV>
[Vollibrespot] : <Moonshine> (213800 ms) loaded
[Vollibrespot] : Event: SinkActive
It looks like loading the track happens after the PlaybackStarted event. If playback continues without any user intervention no additional data structures are emitted until a TrackChanged event occurs in which case a track metadata data structure is emitted.
I'm currently using the token make an independent API call to get the currently_playing track. This requires a Spotify library and reformatting the Spotify response to align with the track metadata data structure Vollibrespot is using, and I would like not to do that stuff :).
I'll have my code in Github when it gets to an alpha quality stage. It's written in python and comprises two servers. One which uses UDP to listen for events / metadata from Vollibrespot and stores them in a data structure in memory and has a HTTP interface. A second server which queries the stored data structure via HTTP REST requests via loop and then displays track metadata and album art using either pygame for console output or Tkinter for X-Windows output. They can run on the same device or on separate devices.
@nathan-sain I am in between a small refactor of the metadata exposed -- there are some discrepancies and confusion from the old spotify-web-connect that I should remove.
e.g kSpDeviceActive
vs kSpPlaybackNotifyBecameActive
are interchanged right now - give me a few days and I'll push a new build that fixes this and also this issue.
@nathan-sain I refactored the exposed metadata, and while at it, added a few more functions. You should now be able to control playback(play/pause/next/prev/volume
) as well via the pipe. Take a look and let me know if you find any issues!
Thanks for the follow-up! I am able to get metadata for in progress tracks.
I'm writing a simple "now playing" display script for a Raspberry Pi and after discovering Librespot didn't emit any playing information I found Vollibrespot. It was exactly what I wanted, so thank you, Ash, for the work you have put into adding this functionality.
I've only found one issue I wanted to raise here and that is when the Vollibrespot daemon starts streaming, no metadata for the currently playing track is emitted over UDP. I see an event handler for PlaybackStarted https://github.com/ashthespy/Vollibrespot/blob/0c510761ea00c7222ea3afd2ecba0c6886fdb6c3/src/meta_pipe.rs#L220 but the handle_track_id function call is commented out. Is that because the track data isn't available at that point? Do you have any plans for implementing a work around? If not, I should be able to use the emitted token to do a separate API call to get the initial track metadata from my script.