Relevant endpoint: https://developer.spotify.com/documentation/web-api/reference/playlists/remove-tracks-playlist/

Something like q or p could work - for example, given this state:

we would show

Crushed - Parkway Drive
All Ngiht - Camo & Krooked
Toi - Worakls
Future Club - Perturbator
Bass Inside - AC Slater

The current song could be either in bold or with (currently playing). So basically the current song and up to 2 before/after (possibly configurable).

Use sbt-buildinfo and/or sbt-dynver.

In 1.3.0, I flipped the order of actions in drop: first we play the next song, then we delete the one playing previously.

This seems to have a negative effect on the UX: the Spotify Desktop app doesn't notice the deletion of a song from a playlist unless one of these happens:

• you open a different page and go back to the playlist
• the song being deleted is the one being played.

That's unfortunate, but the change was required to ensure consistent behavior between Sonos API and Spotify API controlled playback.

It would be nice to find a workaround that will ensure the Spotify app reloads the track list and doesn't show the deleted tracks anymore.

Having a logger would allow us to customize the levels of information being logged in debug/production mode more easily. We already have logback and slf4j in the dependencies because http4s brings them.

I think for the time being (while http4s is pulling in these logging libraries) the best course of action is to follow what we did in https://github.com/pitgull/pitgull: use https://github.com/valskalla/odin with an slf4j bridge.

If odin is to be used, that's blocked by its migration to Cats Effect 3. We also need to upgrade all other deps here to CE3 final before that happens: this would be just http4s and decline-effect.

Use https://developer.spotify.com/documentation/web-api/reference/#endpoint-get-audio-analysis to find the analysis of the currently playing song.

We can cache this eternally for every given song, but probably an expiration of ~5 minutes and/or a size bound would be good enough. The cache needs to be keyed and can't just be "the current song" because we aren't notified of manual song changes by the user and other devices.

For the initial version, we can fetch the features of the song being played on-demand: when the user first uses f (or a different command, if jumping by sections gets a different key than fast-forward), we will get the current playing song's features and jump to the beginning of the next known section. We'll put the features into the cache and possibly get them from that cache next time. For now, no caching is planned.

Currently, the playback control mode is selected on startup and remains that way until the app's exit: if there's a Sonos API at localhost:5005, we use it - otherwise, we call the Spotify API directly.

This could be improved - we have an infallible way of checking whether we should be using Sonos: the Player API.

{
  "device" : {
    "id" : null,
    "is_active" : true,
    "is_private_session" : false,
//here
    "is_restricted" : true,
//
    "name" : "Living Room",
    "type" : "Speaker",
    "volume_percent" : 8
  },
  //...
}

It would fetch the configured ID of the target playlist (or ask to select one, if not set - or if an appropriate flag is provided) and try to add the song to it, then perform the rest of the drop functionality.

I think for starters the selection of the target playlist could consist of enumerating all of the user's playlists (except the one currently playing) along with their IDs, and taking any valid playlist ID as input (as long as the user has edit rights for the playlist). For phase 1, we can skip the list and just have an input here.

Currently, we're using the implicit auth flow, which only gives us tokens that are valid for an hour. A different solution should be used, so that the user doesn't have to reauthenticate every hour.

• Store refresh tokens (#6)
• Use refresh tokens

Probably the best way would be to place the file in a directory compatible with XDG:

XDG_CONFIG_HOME with a default to $HOME/.config, then /spotify-next/config.json.

When using d, you will see the ID and name of the removed track. It would be nice to keep that information stored somewhere in case the user wants to find a song they deleted a while ago (spotify doesn't seem to provide this information).

I think a size-bounded log file would be okay for this, possibly stored next to the config. This would assume we move the config as in #116.

• decline (awaiting 3.x release)
• removing circe-literal
• better-monadic-for replacement: looks like we don't have any recursion in for, so it's not a problem