Spotycast support · Spotify Connect · Debian / Linux · Legacy streamers

Spotycast support: troubleshoot Spotify Connect, Icecast and renderers

Need help restoring Spotify-controlled playback on a Linux or audiophile streamer? Identify the failing layer first, collect useful diagnostic information, then report reproducible bugs and feature requests through the Spotycast GitHub Issues tracker.

Classic: spotifyd → Liquidsoap → Icecast · Premium: Soloist → PipeWire → renderer backend

Start with the symptom, not a full reinstall

Spotify discovery, Linux service status, audio routing, HTTP stream delivery and playback on the receiving device are separate failure points. Check the symptom closest to what you observe.

Spotify device not showing

The endpoint does not appear in Spotify or disappears after a restart. Check service health, LAN visibility and discovery before changing the audio chain.

Troubleshoot discovery →

Device visible, no audio

Spotify can select Spotycast, but nothing plays. Check the correct Classic Icecast mountpoint or Premium renderer-specific audio route.

Diagnose no audio →

Dropouts and buffering

Playback starts but stutters, stalls or disconnects. Separate source interruptions, HTTP buffering, network quality and renderer-side problems.

Investigate dropouts →

Metadata not updating

The audio plays, but track or stream information is missing or stale. Check the metadata path independently from audio delivery.

Metadata troubleshooting →

If the original embedded Spotify Connect integration failed but the streamer still accepts a radio URL or supported rendering protocol, start with Spotify Connect Not Working. Spotycast does not rewrite unsupported firmware.

Before reporting a problem: identify your Spotycast edition

Classic / Free

HTTP radio endpoint via Icecast

Classic receives Spotify playback through spotifyd, routes local audio through Liquidsoap, then exposes an Icecast HTTP stream. Diagnose the Spotify-facing service, Liquidsoap, Icecast and the player opening the configured URL.

  • Check whether Spotify sees the endpoint
  • Verify the configured Icecast mountpoint and stream codec
  • Test the actual HTTP URL in a compatible player
Classic / Icecast architecture →
Premium 3.x

Dedicated renderer backend

Premium uses Soloist, Spotycast Core, PipeWire and the selected Squeezelite/LMS, MPD, Roon or OpenHome backend. Use the Manager status and renderer logs instead of assuming an Icecast endpoint should exist.

  • Check Premium and Soloist credentials privately
  • Inspect Manager backend status and renderer logs
  • Confirm the target renderer is reachable on the LAN
Premium architecture →

Documentation that resolves common installation questions

How to install Spotycast

Reference Debian/Docker/Portainer deployment and the separate Classic and Premium installation and validation paths.

Installation guide →

How Spotycast works

Technical explanation of the Classic radio bridge and Premium direct-renderer architecture.

Architecture guide →

Frequently asked questions

Product scope, receiving protocols, Linux environment and realistic compatibility expectations.

Read the FAQ →

Existing GitHub issues

Check for matching reports, known limitations and existing discussions before opening a duplicate issue.

Browse GitHub issues →

How to write a useful Spotycast bug report

A precise report helps reproduce a failure without requiring access to your devices or credentials. Describe the installation, the expected behavior and the first point where the audio chain stops working.

  1. Identify your edition and releaseSpecify Classic / Free or Premium, Spotycast version, Manager version if relevant, and whether the problem is reproducible after restart.
  2. Describe the host and receiving systemInclude Debian/Linux version, VM/bare-metal/Docker deployment, player or renderer type (Roon, LMS, MPD, Volumio, moOde or OpenHome) and relevant network layout.
  3. State exactly what succeeds and failsIs the Spotify endpoint visible? Does playback start? For Classic, is the Icecast mountpoint reachable? For Premium, which Manager backend and renderer state are shown?
  4. Document the steps to reproduceDescribe what you clicked or ran, what you expected, what occurred instead and whether a recent upgrade or network change triggered the issue.
  5. Attach only redacted logsShare the specific service or renderer logs needed to identify the problem, after removing account details, passwords, API keys, tokens, external IP addresses and private configuration values.

Read-only diagnostic examples for Classic

journalctl -u spotifyd -n 200 --no-pager
journalctl -u liquidsoap -n 200 --no-pager
journalctl -u icecast2 -n 200 --no-pager
curl --max-time 5 http://YOUR_HOST:YOUR_PORT/status-json.xsl

Systemd unit names depend on the installation. In Docker-based deployments, identify containers with docker ps and inspect the relevant one using docker logs --tail 200 <container-name>. For Premium, prefer Manager Status and Renderer logs. Never post full unredacted output.

Security: Never include Spotify credentials, Spotycast Premium installation keys, Soloist API keys, WordPress credentials, application passwords, bearer tokens or complete configuration files containing secrets in a public issue. If an access problem requires private information, describe only the symptom publicly.

Feature requests: describe the playback problem

A useful feature request

“I use Spotycast with Roon and LMS. My receiver accepts an HTTP radio stream, but I need a separate compatible output behavior for a specific playback device. Here is the model, current limitation and desired result.”

A request that needs more context

“Add more options.” Without a target environment, protocol and expected behavior, maintainers cannot evaluate how a change fits Classic or the independent Premium backends.

Include your edition, receiving protocol, actual use case and any compatibility constraints. Keep purchase details and secrets out of public reports.

Premium installation-key or purchase-access issue?

For a Premium access problem, use the established Premium page and customer-access link first. GitHub Issues is useful for technical defects, but public discussions are not appropriate places to disclose order details, license keys or Soloist API credentials.

Never publish a premium_install_key, Soloist API key, payment details, account identifier or order receipt in a public GitHub issue. Report the symptom without exposing private information.