spotify_player

Table of Contents

• Introduction
• Examples
• Installation
• Authentication
• How authentication works
• Why you may be asked to authenticate multiple times
• Client ID and rate limits
• Using a custom client ID
• Features
• Spotify Connect
• Streaming
• Audio Visualization
• Media Control
• Image
• Notify
• Mouse support
• Daemon
• Fuzzy search
• CLI commands
• Commands
• Configurations
• Caches
• Logging
• Acknowledgement

Introduction

spotify_player is a fast, easy to use, and configurable terminal music player.

Features

• Minimalist UI with an intuitive paging and popup system.
• Highly configurable
• Feature parity with the official Spotify application.
• Support remote control with Spotify Connect.
• Support streaming songs directly from the terminal.
• Support audio visualization.
• Support synced lyrics.
• Support cross-platform media control.
• Support image rendering.
• Support desktop notification.
• Support running the application as a daemon
• Offer a wide range of CLI commands

Examples

A demo of spotify_player v0.5.0-pre-release on youtube or on asciicast:

Checkout examples/README.md for more examples.

Installation

By default, the application's installed binary is spotify_player.

Requirements

A Spotify Premium account is required.

Dependencies

Windows and MacOS

• Rust and cargo as the build dependencies

Linux

• Rust and cargo as the build dependencies
• install openssl, alsa-lib (streaming feature), libdbus (media-control feature).

• For example, on Debian based systems, run the below command to install application's dependencies:

  shell sudo apt install libssl-dev libasound2-dev libdbus-1-dev

• On RHEL/Fedora based systems, run the below command to install application's dependencies :

  shell sudo dnf install openssl-devel alsa-lib-devel dbus-devel

  or if you're using yum:

  shell sudo yum install openssl-devel alsa-lib-devel dbus-devel

Termux (Android)

• Two default components require a JVM context that Termux processes don't have: the default TLS backend (rustls-platform-verifier, panics during the auth token exchange) and the rodio audio backend (cpal's AAudio host, panics when streaming starts). Build with the native-tls feature and the pulseaudio backend instead:

shell pkg install rust openssl pulseaudio cargo install spotify_player --no-default-features --features pulseaudio-backend,media-control,native-tls

This makes authentication, the Web API, and remote device control work. Integrated streaming additionally requires patching librespot's compile-time OS identity (librespot-core's config::OS) to "linux" via [patch.crates-io], because librespot built for target_os = "android" presents the Android-app identity, which Spotify rejects for keymaster-minted credentials.

Binaries

Application's prebuilt binaries can be found in the Releases Page.

Note: to run the application, Linux systems need to install additional dependencies as specified in the Dependencies section.

Homebrew

Run brew install spotify_player to install the application.

Scoop

Run scoop install spotify-player to install the application.

Cargo

Install via Cargo:

cargo install spotify_player --locked

Arch Linux

Install via Arch Linux:

pacman -S spotify-player

Note: Defaults to PulseAudio/Pipewire. For a different backend, modify the official PKGBUILD and rebuild manually. See Audio Backends.

Void Linux

Install via Void Linux:

xbps-install -S spotify-player

FreeBSD

Install via FreeBSD:

pkg install spotify-player

NetBSD

Install via NetBSD:

pkgin install spotify-player

Build from source on NetBSD:

cd /usr/pkgsrc/audio/spotify-player
make install

NixOS

spotify-player is available as a Nix package. Install via:

nix-shell -p spotify-player

To build from source locally, run nix-shell in the root of the source checkout. The provided shell.nix will install prerequisites.

Docker

Note: The streaming feature is disabled in the Docker image.

Download the latest Docker image:

docker pull aome510/spotify_player:latest

Run the Docker container:

docker run --rm -it aome510/spotify_player:latest

To use your local config and cache folders:

docker run --rm \
-v $APP_CONFIG_FOLDER:/app/config/ \
-v $APP_CACHE_FOLDER:/app/cache/ \
-it aome510/spotify_player:latest

Authentication

spotify_player requires a Spotify Premium account and authenticates against the Spotify Web API using the OAuth 2.0 authorization code flow with PKCE. No client secret is stored or required.

The simplest way to authenticate is to just run the application — on first use it prompts for whichever credentials are not yet cached. Each prompt opens the Spotify authorization page in your browser; after you approve access, Spotify redirects to a local loopback address (login_redirect_uri, default http://127.0.0.1:8989/login) where spotify_player captures the authorization code and exchanges it for an access token. Credentials are cached in the application's cache folder, so this is a one-time step per machine.

Alternatively, run the spotify_player authenticate CLI command to authenticate all required credentials up front — useful for setting things up ahead of a daemon or headless launch. Unlike a normal launch, authenticate always forces fresh interactive logins, ignoring cached credentials, so it can also be used to re-authenticate from scratch.

How authentication works

Two kinds of credentials are involved:

• One or two Web API tokens, used for REST calls (playback control, library, search, playlists, etc.). The default setup uses ncspot's client ID. When a custom client_id is configured, its token is used first and a separate ncspot token provides fallback access.
• A librespot session, used for the streaming feature (direct playback and Spotify Connect device registration).

They authenticate through your Spotify account; the client ID presented to Spotify differs between credentials (see below).

Why you may be asked to authenticate multiple times

With the streaming feature enabled (the default), the first launch normally opens the Spotify authorization page twice, in this order:

1. The Web API token, presented under the configured client_id (ncspot's by default). This is cached as <client_id>_token.json.
2. The librespot session credentials, presented under Spotify's official client ID. These are cached as credentials.json.

These are two independent OAuth flows with two different client IDs, so Spotify requires a separate approval for each, and each credential is cached separately in the cache folder. This is a one-time step per machine — subsequent launches reuse and silently refresh them unless a cache is cleared or a credential is revoked.

When a custom client_id is configured, an ncspot fallback Web API token is also requested and cached as <ncspot_client_id>_token.json. Its OAuth callback always uses http://127.0.0.1:8989/login; login_redirect_uri applies only to the custom client. A custom setup with streaming enabled can therefore require three approvals on first launch. Web API token cache filenames include their client IDs, so changing client_id requires a new approval instead of reusing a token issued to another client.

A fallback ncspot client is integrated since the custom client might not be registered with extended quota mode and could therefore doesn't have access to certain endpoints.

The spotify_player authenticate command runs every required flow in one go, forcing a fresh login for each. Without streaming, the librespot flow is omitted, leaving one Web API approval for the default setup or two for a custom-client setup.

Client ID and rate limits

Every request to the Spotify Web API is attributed to a Spotify application, identified by a client ID. The client ID — not your account — determines the API quota you are subject to.

By default, spotify_player uses ncspot's client ID. This client ID is shared by many users, so its API quota can be exhausted by aggregate usage and cause 429 Too Many Requests responses. Registering and configuring your own client ID is strongly recommended so routine requests use a quota dedicated to your Spotify application.

The ncspot client ID remains available as a fallback because it is registered in extended quota mode and predates Spotify's November 2024 Web API changes. It can access endpoints (browse, personalized content, generated playlists, …) that newly-registered applications can no longer use.

When a custom client_id is configured, spotify-player sends most Web API requests through that client first. If Spotify rejects custom-client request with any 4xx response, the request is attempted once through ncspot. Successful requests and failures outside the 4xx range do not trigger fallback.