starred/spotify-player

Fork 0

mirror of https://github.com/aome510/spotify-player.git synced 2026-04-26 01:15:55 +03:00

[GH-ISSUE #103] feature suggestions/requests #41

New issue

Closed

opened 2026-03-02 23:43:57 +03:00 by kerem · 9 comments

kerem commented

2026-03-02 23:43:57 +03:00

Owner

Originally created by @sewnie on GitHub (Jan 9, 2023).
Original GitHub issue: https://github.com/aome510/spotify-player/issues/103

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

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

λ spt playback
🔀 ▶ Warakumbla - Hypothermia

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.

Originally created by @sewnie on GitHub (Jan 9, 2023). Original GitHub issue: https://github.com/aome510/spotify-player/issues/103 ~~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](https://st.suckless.org/patches/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.

kerem

2026-03-02 23:43:57 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@sewnie commented on GitHub (Jan 9, 2023):

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

@sewnie commented on GitHub (Jan 9, 2023): 2 - https://github.com/librespot-org/librespot/wiki/Events

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@sewnie commented on GitHub (Jan 9, 2023):

   Compiling spotify_player v0.10.0 (/tmp/kiss/14173/build/spotify-player/spotify_player)
warning: function `get_track_album_image_url` is never used
  --> spotify_player/src/utils.rs:63:8
   |
63 | pub fn get_track_album_image_url(track: &rspotify::model::FullTrack) -> Option<&str> {
   |        ^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

this can fulfill feature request 1!

@sewnie commented on GitHub (Jan 9, 2023): ``` Compiling spotify_player v0.10.0 (/tmp/kiss/14173/build/spotify-player/spotify_player) warning: function `get_track_album_image_url` is never used --> spotify_player/src/utils.rs:63:8 | 63 | pub fn get_track_album_image_url(track: &rspotify::model::FullTrack) -> Option<&str> { | ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(dead_code)]` on by default ``` this can fulfill feature request 1!

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@sewnie commented on GitHub (Mar 19, 2023):

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?

@sewnie commented on GitHub (Mar 19, 2023): > 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?

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@sewnie commented on GitHub (Sep 7, 2023):

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.

@sewnie commented on GitHub (Sep 7, 2023): 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.

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@aome510 commented on GitHub (Sep 7, 2023):

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 commented on GitHub (Sep 7, 2023): > 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?

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@aome510 commented on GitHub (Sep 7, 2023):

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

@aome510 commented on GitHub (Sep 7, 2023): socket should be really fast. The slowness you see should mostly come from network request to get Spotify data.

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@sewnie commented on GitHub (Sep 7, 2023):

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?

@sewnie commented on GitHub (Sep 7, 2023): > 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. ![image](https://github.com/aome510/spotify-player/assets/47404953/da24dd4d-6ecc-4894-900a-e649a2ac4d56) > 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?

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@aome510 commented on GitHub (Sep 7, 2023):

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?

@aome510 commented on GitHub (Sep 7, 2023): > 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`?

kerem commented

2026-03-02 23:43:58 +03:00

Author

Owner

@sewnie commented on GitHub (Sep 7, 2023):

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

@sewnie commented on GitHub (Sep 7, 2023): Forget the FIFO, i'd rather have the 'retrieve data remotely' problem gone, making a new issue

kerem referenced this issue

2026-03-14 12:36:35 +03:00

[GH-ISSUE #41] Default device #948