Gatefold - A Display For Raspotify
JamieGoodson opened this issue · 25 comments
Raspotify is just a package
- I know Raspotify is just a package
Due Diligence
- I have done my due diligence
What can we do to make Raspotify more awesome?
Sorry if this is the wrong place or completely inappropriate - I wanted to share a small project I've been working on for our house.
We have Raspotify setup in our living room with our hifi, with different housemates using their phones to connect to Spotify throughout the day. I thought it'd be nice to have a small display showing what track is currently playing, so I created Gatefold:
Gatefold - A Display For Raspotify
- Displays currently playing track
- Suitable for communal areas where lots of different people connect to Raspotify daily
- QR code takes you directly to the song on the Spotify app
- No login required
It works by taking advantage of Librespot's onevent.
I imagine this may be useful for many other current/future Raspotify users. Perhaps Gatefold could get a small mention on the wiki Community Coded Extras page? If not, no worries!
Thanks very much for maintaining Raspotify - it's been a life saver 🙂
Please ignore me, I didn't realize the wiki was open to public editing
I added more detailed player events to librespot dev a while back and wrote a python script that broadcasts events via UDP Multicast that may make your job easier. You can test it out on a Bookworm compatible OS.
You wouldn't really need to rely on anything external for metadata and whatnot.
Once Raspberry Pi OS switches to Bookworm and a couple things drop in librespot dev I plan on switching back to dev in Raspotify and I would much like to collaborate.
Ah that's perfect, with such detailed events I could drop the Spotify dependency entirely then. Will be keeping a keen eye on when Raspotify officially switches over. Am also open to collaborating 🙂
Ah that's perfect, with such detailed events I could drop the Spotify dependency entirely then. Will be keeping a keen eye on when Raspotify officially switches over. Am also open to collaborating
That was the idea. When librespot switched to a newer API we were getting that info for free anyway it was just a matter of exposing it. Broadcasting via UDP Multicast also means that the display doesn't even need to be running on the same machine. Anything on the same network can listen for the events.
How's the reliability compared to a TCP approach (eg websockets)? If, say, a user is spamming the volume buttons or skipping through different tracks in quick succession (all of which would fire an event), do they arrive at the destination in the correct order?
I'd test your branch for myself but I don't have a compatible spare machine atm 😢
I fixed that too. Currently events start a new thread each time they are fired which can lead to events being out of order depending on how the event handler script deals with them since it's asynchronous it's possible to have multiple instances of the same script doing things at the same time.
In the new version there is only ever one event handler thread, events are buffered and always fired in the order received synchronously within the handler thread. The result is that events are always fired in order.
How's the reliability compared to a TCP approach
UDP isn't reliable. It doesn't care who's listening and if anyone has received the message. It's basically shouting into the void.
That's kinda the point though, not to care on the event sender side of things. It's up to whatever is listening to deal with the events.
If you could though, give me a list of things you're currently getting from the Spotify API? That way if there's anything you're missing that we can get I can hopefully make sure it ends up in the events.
My dream would be something that could be packaged as a .deb that ran completely local on whatever you installed it on being it the same machine as Raspotify is installed on or not. I'd love to have a package like that in the Raspotify repo.
In the new version there is only ever one event handler thread, events are buffered and always fired in the order received synchronously within the handler thread. The result is that events are always fired in order.
Ah that's perfect then, great solution!
If you could though, give me a list of things you're currently getting from the Spotify API?
Sure, I only hit one Spotify endpoint to retrieve:
- Track ID
- Track name
- Album image(s)
- Artist(s)
- External Spotify URL (for the QR code)
My dream would be something that could be packaged as a .deb
Referring to Gatefold? Hmm yes that would be great, I'll look into this. One issue right now though is that the default Raspotify service runs as a DynamicUser, so a replacement service is needed for Gatefold to run its event script. Or in future would Raspotify have a built-in option in the config to turn on UDP multicasting?
What about background and foreground colors?
As far as the UDP stuff yes, the script will come with Raspotify. All a user will have to do is uncomment a line in the config to enable it.
My plan is also to include full metadata in the preloading event so that you can also do an "Up Next" bubble sorta like what is shown in the desktop client:
Controls aren't really a goal at the moment but the "playing from" bit and a position bar just for display purposes could be a nice addition though. I'd steer clear of using the Spotify logo/icon though ofc.
What about background and foreground colors?
The colour palette is extracted from the album image on the fly
I like the idea of additional elements like "Up next" and a track position bar 👍 Though perhaps this should only be visible on larger screens (may appear too cramped/hard to read on a smaller tablet, like the 7" one I'm using in our living room atm).
The colour palette is extracted from the album image on the fly
Spotify has specific metadata fields/attrs for background and foreground colors. You wouldn't need to calculate those on the fly unless for some reason they were absent in the metadata. I'm pretty sure librespot has them buried somewhere? I think it's just a matter of exposing them?
I like the idea of additional elements like "Up next" and a track position bar +1 Though perhaps this should only be visible on larger screens (may appear too cramped/hard to read on a smaller tablet, like the 7" one I'm using in our living room atm).
I could go either way on the position bar but I think the "Up Next" notification would be nice ofc provided there's screen space.
I'm pretty sure the background color is calculated probably in a very similar way that you're doing. I'm not sure how the foreground color is calculated but I'm pretty sure that the intention would be for displays to use that as the text color. Although I'd prob run it though some kind of accessibility check to make sure it provides enough contrast to be readable.
Spotify has specific metadata fields/attrs for background and foreground colors
This info doesn't seem to exist in the Spotify Web API so I'm curious as to where librespot gets this info. In any case, that's great - this will be very useful indeed!
Checking the code, it looks like it pulls it from some lyrics endpoint ("/color-lyrics/v2/track/{}")
I'm curious as to where librespot gets this info
Librespot doesn't necessarily stick to the public API's.
Checking the code, it looks like it pulls it from some lyrics endpoint ("/color-lyrics/v2/track/{}")
Yep, I got to check if we're already using that by default for anything? The general rule of thumb is that they won't do any additional API calls then necessary so if it's not being used already I prob won't be able to expose it in the events. I knew it was there somewhere, but like I said I'm not 100% sure we can get it for events? If we can't it's no lose you've made it this long without it, if I can I'll expose it.
Yeah all good, I can make do without if you're unable to expose it
Ideally a user would have to do little to no setup. Given that the events will have everything you need you shouldn't need to use Netlify and you shouldn't need to register an app with Spotify. Ideally it should all run locally on the machine without anything external and would write directly to the framebuffer and/or host a local webpage. I think @dtcooper has some framebuffer stuff we might be able to use?
This issue has been marked as stale. It will closed in 7 days if there is no activity.
I think @dtcooper has some framebuffer stuff we might be able to use?
eh, my library python-dispmanx doesn't work well on modern raspberry pi OSes with the stock kernel boot configs, so I don't really recommend it. Having said that, if you mess around with your kernel config per the library's docs, it'll work well!
This issue has been marked as stale. It will closed in 7 days if there is no activity.
This issue has been closed due to lack of activity.