nemoandrea / spotistation Goto Github PK

Verify if the Raspberry Pi Zero 2W has enough horsepower to run the SpotiPlayer smoothly.

If so, I will make an alternative printable part for the Zero. It would be great if the zero is powerful enough as it could make the project more affordable to build.

Even with gpio_slowdown, there is still a slight flicker visible on the display on rare occasions. Worse still is that at the centerline of the display a column of pixels has a slight persistent flicker that is not very visible when looking at it directly, but becomes very visible during rapid eye movement (pan).

It is not a big problem for the experience, as it looks fine when looking directly at the display, but a fix should be found for it longterm.

Suggestions on configuration options would be appreciated. The display settings can be found in display.py

Add stemma QT based ambient light sensor for automatic light dimming. Would need some kind of robust way to self-calibrate on-location.

The main play/pause button on the printer is the central user interaction element, but at the moment the experience is usable, but not as smooth or polished as I would like.

There are two main reasons for this ⬇️

1. The current main button mechanism uses a standard MX-style switch. This is mechanically ok, but unless you get a very heavy spring, the return force is a bit lacking.

2. In addition, the printed mechanism (two pins) to keep the round button aligned have quite a lot of friction when they are fresh out of the printer. After a while it becomes smooth enough as the printed parts wear out any imperfections in the sidewal.

Help or advice on improving or circumventing the above two issues would be appreciated. Ideally solutions should involve parts that can be sourced relatively easily.

Note
The SpotiStation will show up as a smart Spotify speaker on the network thanks to Spotifyd. This allows anyone on the network to playback their music on the SpotiStation by selecting it as a playback device.

When selecting the SpotiStation as a playback device from a Spotify account other than the signed in account the device will crash. When the signed-in account starts manually casting to the SpotiStation (thus overriding its default playlist rotation), no such error occurs and the external Spotify Account can join the speaker session without issues.

Fixing the initial Speaker Session error would make it a lot more convenient for visitors to use the SpotiStation.

It would be nice if for a given playlist or song to be able to display it's spotify code. Would need a way to scrape the code automatically. Need to find a way to integrate that without complicating the interface (maybe one of the back buttons)

The player should have some basic logging system that keeps track of errors and crashes.

Energy use

The power consumption of the SpotiStation is currently not measured, which makes estimating the running (energy) costs of the device tricky.

In addition, it might be that the current power supply is overkill for the job and a smaller and cheaper supply will do just as well.

Solution

1. Run measurements with socket power monitor to see how much power display uses (at 50% brightness and 100% brightness)
2. Re-evaluate the suitability of current power supply

Add the ability to play local MP3 files on the player, keeping as much of the interface and configuration similar to the spotify based playback.

Would probably required a significant refactoring of the code to make it more general.

Motivation

Since a spotify subscription is not cheap (120euro per year at time of writing, single user) having this as an alternative would make it more attractive for users who only need a limited selection of songs.

Add miscellaneous logging of non-error stuff. E.g. hours used per day, playlist history and maybe volume behaviour. Make it easy for administrators to evaluate if the player is used (well).

The spotipy.current_playback() function will time out after about 10 minutes of inactivity (e.g. when the system is left in the paused state). This function will then return None until playback is restarted manually.

The current dirty fix is to just throw an exception and have the player restart (which will automatically resume playback).

Solution needs to replace the current 'just throw an exception' solution here