Player hooks with data arguments

[apprehensions]

Is your feature request related to a problem? Please describe.
Recently, I have stopped using spotify-player simply because libreapot does not has support for external connections such as last.fm, and can not do notifications without Dbus.

Describe the solution you'd like
A hook system that launches a program with arguments set in the configuration for events such as pre, post, during (second interval) for sub-events for playing, pausing, skipping, etc..

I can use these to pass to notification or lastfm scrobller clients.

Describe alternatives you've considered
Using librespot or spotifyd directly, I believe librespot has direct support for this feature, so I don't think it would be trivial to implement it here.

[apprehensions]

@aome510 i would like to hear from this.

i am tired of the propietary spotify client.

[aome510]

I've been quite busy lately, so I won't be able to implement this soon. However, will put this up in my TODO list and see look into ways to integrate the last.fm APIs, if any.

[apprehensions]

well, this feature request is for hooks, which is alot simpler than implementing the last.fm API, since that can be handled by another program making the stack simpler.

[aome510]

Plan to implement this next week or so. Does writing player events in a cache file work? You can write a script to watch for changes in that file every second or so, and port that to last.fm client. Lmk if I need to include any fields other than the event data (I plan to include the timestamp).

[apprehensions]

honestly been using the propietary spotify client for a long while now, i'd much rather have librespot itself actually supporting this shit rather than me having to send last.fm api requests constantly

[aome510]

Just saw this issue: jpochyla/psst#424. Look like lastfm scrobbling is supported via Spotify connect, so it should work by default with spotify_player. I just double check on last.fm website and it shows all the scrobbles when I use spotify_player. Can you confirm? If that's the case, I'll close this issue.

[apprehensions]

Wow, okay!!!! I'll check tommorow!!

I will be very happy if this is true.

[apprehensions]

SEEMS TO WORK!!
although, spotify cant quite see what i'm playing, so that spotify yearly thing wont quite work

[apprehensions]

thank u

[aome510]

although, spotify cant quite see what i'm playing, so that spotify yearly thing wont quite work

Related librespot-org/librespot#913. That's one thing I miss from the official app and wish that librespot figure out ways to reverse-engineer the feature.

[apprehensions]

It is a bit infuriating to be honest, considering its been a problem for 4 years and no one had stepped up and reversed engineered it :(

[apprehensions]

Wait, this issue still remains.

[apprehensions]

I do want to have some form of player hooks to be honest; my use case being to avoid constant D-Bus requests.

[aome510]

I do want to have some form of player hooks to be honest; my use case being to avoid constant D-Bus requests.

Does writing player events into a file work? I'm not too familiar with the player hook concept and how to implement one.

[apprehensions]

Player hooks is to launch a program with certain metadata (such as song, album, title) as arguments, on certain events (such as play, new song, pause, etc)

[aome510]

Implemented in #244. Refer to https://github.com/aome510/spotify-player/blob/add-player-hook/docs/config.md#player-event-hook-command for how to use the command.

[apprehensions]

why json? :(

[aome510]

why json? :(

for consistency with CLI commands' output and because the app already supports exporting Spotify data in JSON format.

[apprehensions]

Why not ususe JSON for big Spotify data? For example for simple data it should simply be it in plain text, and the arguments to be passed as the arguments themselves:

script "Playing" "Artist" "Album" "Song", this ensures that scripting is very easy. I'd appreciate it if you did this as this is what I had expected..

[apprehensions]

I can't use this feature; setting player_event_hook_command to a valid binary path gives: player_event_hook_command: None.

player_event_hook_command = "spotify_player-hook"

2023-09-07T16:28:20.475855Z  INFO spotify_player: General configurations: AppConfig { theme: "sewn", client_id: "XXXXXXXXXXXXXXXXXXXXX", client_port: 8080, copy_command: Command { command: "xclip", args: ["-sel", "c"] }, player_event_hook_command: None, playback_format: "{track}\n{artists} - {album}\n{metadata}"...

[aome510]

Please refer to the linked document to use a correct format. It should be player_event_hook_command = { command = "spotify_player-hook", args = [] }

Regarding why JSON but not plain text with arguments,

1. different events have different fields, passing the fields as command's arguments simply does not scale.
2. script can be arbitrarily complexed as user wants, the passing data to the script logic from spotify_player side is not. As a result, the passing data logic should be simple (e.g passing the event as a single input).

[apprehensions]

different events have different fields, passing the fields as command's arguments simply does not scale.

#!/bin/sh

echo "command: $1"

case "$1" in
        Changed) echo "old_track_id: $3, new_track_id: $3" ;;
        Playing) echo "track_id: $2, position_ms: $3, duration_ms: $4" ;;
        Paused) echo "track_id: $2, position_ms: $3, duration_ms: $4" ;;
        EndOfTrack) echo "track_id: $2" ;;
esac

I hightly suggest to you to please use a arguement system, as it makes my life and others much easier when scripting for spotify-player.

[aome510]

I hightly suggest to you to please use a arguement system, as it makes my life and others much easier when scripting for spotify-player.

Ok, I'll think about it.

[aome510]

Just a note that with the arguments approach, new user will be confused between the arguments, e.g is it Changed old_track_id new_track_id or Changed new_track_id old_track_id? Then they are required to actually read the document, which many don't usually.

[apprehensions]

Well? They need to read the docs to understand what the hooks do, their arguments and commands to begin with.

[aome510]

Should be updated with #251.