feature suggestions/requests

[apprehensions]

1. download the current playing song's album cover into a file or into a cache for another script to use; my usecase for this is to display the album cover with an image viewer, as i missed this feature from playing music with mpv.
2. display the album cover as braille; my usecase for this is with st boxdraw, as it can render braille characters as block. (might be replaced by sixel) viuer backend request, not spotify-player

1. support querying of status, like in spotify-tui, with the ability for custom format:

λ spt playback
🔀 ▶ Warakumbla - Hypothermia

2. support running a command on new song or supply current playing song, data, albumcover file, volume on music event to an external command via configuration, or a really over-engineered fifo.

[apprehensions]

2 - https://github.com/librespot-org/librespot/wiki/Events

[apprehensions]

support running a command on new song or supply current playing song, data, albumcover file, volume on music event to an external command via configuration, or a really over-engineered fifo.

a workaround to this would be to wait for a new file in the album cover cache directory i guess?

[apprehensions]

I found a workaround to the slow cli commands, which is to use the new hooks feature to output the tracks name to a file in ~/.cache, and have a seperate program read it.

I'm still unsure why spotify-player uses a network socket; it should be using a FIFO as its much faster than performing a network request.

[aome510]

I'm still unsure why spotify-player uses a network socket; it should be using a FIFO as its much faster than performing a network request.

Not sure how FIFO can be implemented as a way for CLI to communicate with another running client. Do you mind to elaborate?

[aome510]

socket should be really fast. The slowness you see should mostly come from network request to get Spotify data.

[apprehensions]

Not sure how FIFO can be implemented as a way for CLI to communicate with another running client. Do you mind to elaborate?

You could make a FIFO at /tmp, have a program write a command to it (such as 'get playback'), and that program will read from the FIFO after writing, in which case spotify_player will get that command, and write to the FIFO, which the program will retrieve.

The slowness you see should mostly come from network request to get Spotify data.

Wait what? Why is this done? Shouldn't spotify_player store the current playing song? Why is this required for retrieving data that is already available?

[aome510]

Wait what? Why is this done? Shouldn't spotify_player store the current playing song? Why is this required for retrieving data that is already available?

Yes, playback, specifically, can be parsed from the application's state so don't really need to make an API call. Getting playback through an API call was implemented for the first iteration because it's simpler and similar to the way the client handles other get commands. Please create an issue with description + observed runtime for get playback so that people can track it if you want get playback to be faster.

You could make a FIFO at /tmp, have a program write a command to it (such as 'get playback'), and that program will read from the FIFO after writing, in which case spotify_player will get that command, and write to the FIFO, which the program will retrieve.

If client and server both write to the same file, how does one differentiate between the other? Do you mean client and server have different FIFO file, server writes to /tmp/command, and client writes to /tmp/command_result?

[apprehensions]

Forget the FIFO, i'd rather have the 'retrieve data remotely' problem gone, making a new issue