[API Request] Feature request: Add explicit negative preference (“dislike”) to the Subsonic API

[squintgit]

Type of change

API Clarification

Proposal description

The Subsonic API currently supports star ratings and favorites, but has no way to represent a negative preference (dislike / thumbs down).

In practice, clients and servers are forced to overload 1-star ratings to mean “dislike,” which is ambiguous. A low rating may indicate indifference rather than active dislike, and this prevents clients from implementing a clear, first-class thumbs-down interaction.

I’m proposing the addition of an explicit negative preference signal, for example:

• preference: like | neutral | dislike
  or
• a dedicated dislike: true|false field

This would be backward-compatible and optional. Existing clients could ignore the field, while servers and clients that support it could use it to improve shuffle, radio, and recommendation behavior without abusing star ratings.

Without an API-level representation of negative preference, Subsonic-compatible clients cannot implement a true dislike feature.

One practical example where this limitation becomes visible is CarPlay and Android Auto. Many clients do not expose star ratings in these environments, only a single “favorite” or “like” action. Without a negative preference signal, users cannot indicate “do not play this again” in contexts where minimizing interaction is especially important. A first-class dislike field would allow clients to expose a single, unambiguous action instead of relying on nested menus or overloading star ratings.

I believe this fits well as a backward-compatible extension and would benefit both server-side logic and client UX without breaking existing implementations.

Backward compatibility impact

This proposal can be fully backward-compatible if implemented as an optional extension:

• Servers may expose the field; clients may ignore it.
• Older clients/servers that do not recognize the new field will continue to function unchanged.
• Default behavior when the field is missing should be treated as neutral (no explicit preference).
• No existing endpoints need to change semantics; this can be added as a new optional attribute in existing responses, and a new optional parameter in a new or existing “set” endpoint.

If the project prefers to avoid modifying existing response schemas, an alternative is to introduce new endpoints for setting/getting the preference while keeping existing endpoints untouched.

Backward compatibility

• No backward compatibility impact.

API details

Proposed concept: a first-class negative preference signal for media items (primarily songs).
Two possible models:

Option A (recommended): ternary preference

• Field name: preference
• Values: like | neutral | dislike
• Scope: per user, per media item
• Where exposed: include in song payloads returned by browse/search/playlist endpoints (where ratings/favorites are already commonly surfaced)
• How set: new endpoint or extension of an existing “setRating”/“star” style endpoint with an additional parameter, e.g.:
  • setPreference(id, preference) where id is songId (and optionally albumId/artistId later)
• How cleared: preference=neutral (or omit to clear)

Option B: boolean dislike

• Field name: dislike
• Values: true|false
• Notes: less expressive than Option A but simpler.

Rationale: star ratings are ambiguous and not reliably surfaced in clients (e.g., CarPlay UIs often only surface a single “favorite” action). A distinct preference signal allows consistent UX and server-side logic (shuffle/radio/recommendations) without abusing 1-star ratings.

Security impacts

No direct security impact beyond existing authentication/authorization controls for user-specific metadata. The server must ensure preference changes apply only to the authenticated user’s library context, same as favorites/ratings.

Potential issues

• Interoperability: clients may interpret “dislike” differently (e.g., “never play again” vs “less often”). Recommendation: define expected semantics as “negative preference signal” without mandating playback behavior.
• Migration: servers that previously used 1-star as “dislike” may want a migration path (optional).
• Scope creep: requests to apply preference at album/artist level. Recommendation: start with song-level only.
• UI behavior: clients may want both star ratings and preference; clarify they are separate signals.

Alternative solutions

• Continue using 1-star rating as a proxy for dislike (current workaround), but it remains ambiguous and many clients don’t surface ratings well.
• Client/server-specific extensions (out-of-spec) can implement dislike today, but that fragments compatibility across the ecosystem.
• Add a “hidden”/“skip” list feature instead of dislike; this solves “don’t play again” but not the broader negative preference signal.

[ztx-lyghters]

This is REALLY needed for multi-user servers

[squintgit]

What is the reason? I filed this.. so just curious.

[ztx-lyghters]

What is the reason? I filed this.. so just curious.

So multiple people could share and contribute to a single server, but also be able to filter out unwanted music from other users

[yatul]

E.g. I have a Navidrome server for my family, and there are a lot of children's songs that I personally don't like to play in my own player. Instead of marking all these tracks with a 1-star rating, I'd prefer to be able to mark the whole album or specific tracks as "disliked" or "not wanted".

[king8084]

How is this not an option lol