[Feature Request] Add TRACK_NAME, ARTIST_NAME env vars when calling on_song_change_hook

[ceuk]

Hey,

Trying to implement song change notifications currently requires fetching the track info via playerctl or a similar method (unless I'm missing something) - which can be problematic (see: #337 #503).

Spotifyd already sets two env vars (TRACK_ID and PLAYER_EVENT).

Would it be viable to add more information about the track in context? It seems to make sense from a design perspective to provide this when running the hook and would have the advantage of simplifying common uses of the hook (e.g. generating notifications and I imagine many others).

Huge appreciation for all your work and thanks for reading :)

[ceuk]

Had a look at the source code and it looks like the event (and available parameters) are basically just being proxied from Librespot. So I guess the change would have to be made upstream first?

I'll raise an issue there too and reference this issue.

[ceuk]

Quick update on this: looking back at previous discussions over on Librespot, it looks like they're generally against exposing metadata from a design POV to keep the core library uncluttered. As such, they would suggest it should be something that daemons such as Spotifyd handle.

Perhaps we could use the TRACK_ID provided by the subprocess to fetch some song metadata manually?

[dheatovwil]

Perhaps we could use the TRACK_ID provided by the subprocess to fetch some song metadata manually?

Apparently using Spotify Web API is not ideal as that would require an API key, I figured out a hacky way that uses the spotify player page, by accessing https://open.spotify.com/track/$TRACK_ID, some metadata like title and author can be extracted directly from the meta tags using regex. A short demo:

curl -s https://open.spotify.com/track/$1 > .spotmeta.temp

TITLE=$(grep -o -P "(?<=<meta property=\"twitter:title\" content=\").*?(?=\" \/>)" .spotmeta.temp)
AUTHOR=$(grep -o -P "(?<=<meta property=\"twitter:audio:artist_name\" content=\").*?(?=\" \/>)" .spotmeta.temp)```

[ceuk]

#452 over on Librespot has been finalized/merged sans Track Name which pretty much puts to bed (for the foreseeable at least) the hope that we can get easy access to the metadata from there.

Given the apparent complexities of fetching the metadata from within Spotifyd, that really leaves the maintainers with the decision of whether or not they feel a fairly opinionated module (that likely requires API keys as @dheatovwil mentions) is appropriate/belongs within the Spoftifyd daemon.

[ejiektpobehuk]

It's a workaround but it works quite good. I use mpris to locally fetch metadata in hooked software (it shows notification).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Saliba-san]

To anyone facing the same task, the metadata is available through the dbus/mpris metadata property. playerctl for some reason is too slow so you can fetch the metadata using directly the dbus-send command:

dbus-send \
    --print-reply \
    --dest="org.mpris.MediaPlayer2.spotifyd.instance$SPT_PID" \
    /org/mpris/MediaPlayer2 \
    org.freedesktop.DBus.Properties.Get \
    string:"org.mpris.MediaPlayer2.Player" string:'Metadata'

The SPT_PID is the spotifyd PID and can be fetched with pidof:

SPT_PID="$(pidof -s spotifyd)"

and to parse the output I created a not so good function:

function parse_metadata() {
     local mdata="$1"
     local attribute="$2"

     grep -w -A 2 "$attribute" <<< "$mdata" \
              | sed ':a;N;$!ba;s/array \[\n//g'\
              | awk -vFPAT="([^ ]+)|(\"[^\"]+\")"  'NF==3{print $3}' \
              | sed 's/"//g'
}
title=$(parse_metadata "$metadata" "xesam:title")
artist=$(parse_metadata "$metadata" "xesam:albumArtist")
album=$(parse_metadata "$metadata" "xesam:album")

where $metadata is the output of the dbus_send command.

[eladyn]

Fixed by #1317.