[API Request] Ability to set and get ratings on AlbumID3 and ArtistID3 types

[dweymouth]

Type of change

API extension

Proposal description

Some servers may already support this but officially in the last Subsonic API spec, only songs and music folders (Album and Artist, but not AlbumID3 and ArtistID3) could have ratings. We should extend setRating to support IDs for ArtistID3 and AlbumID3 entities, and return the rating in the JSON/XML response in the getAlbum and getArtist calls.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

As described above. Add userRating (edit: and averageRating) as properties to the AlbumID3 and ArtistID3 types.

Security impacts

No response

Potential issues

No response

Alternative solutions

No response

[Tolriq]

Beware of the meaning of ratings. There's ratings like the one you get from last.fm and there's userRatings.

Both should be supported and clearly disctincted.

[deluan]

AFAIK, Ratings in the Subsonic API only means userRatings, it does not fetch/submit ratings to Last.fm or any other external service. If we want to support that, we need to create an extension for that.

[dweymouth]

Tolriq is right though, that the property name should be userRating, not rating to keep it in line with the rest of the API. There is the concept of averageRating for album and artist (directories only, not ID3) and we probably want to add that as well to the ID3 types.

[ghenry22]

AFAIK, Ratings in the Subsonic API only means userRatings, it does not fetch/submit ratings to Last.fm or any other external service. If we want to support that, we need to create an extension for that.

The original subsonic does not submit anything anywhere. The ratings are purely user ratings as you say.

the ability to set and get ratings is really super limited.

I would propose to run through the api and look at all the places it would be useful. For instance when fetching random or by genre or other criteria having the option get highly rated or apply a rating filter of above or below certain stars would be excellent.

[holocronweaver]

What would be required to add album and artist rating APIs?

Would love to see this API added. I rarely rate individual songs, but I almost always rate albums (and sometimes artists in the event they don't release albums). Historically most professional music ratings are based on albums. While the web has made standalone singles more common, for certain artists and genres, albums are still coherent pieces of work that can be rated as a whole. Album ratings are usually where I start when narrowing down what to listen to or delete. I'm surprised OpenSubsonic doesn't already support this.

[deluan]

I think we could introduce a new userRating attribute in all elements (folders, artists, albums and songs/child), and it could be a float with .5 steps, so it would support half-stars as well.

This could be a simple addition. What do you guys think?

[kgarner7]

1. Why not 1-10 (easier to represent, same result)? Or, if you'd like to support broader values, 1-100?
2. You would naturally need a new extension to specify support for this
3. Does a client send both 1-5 and the new scale when starting? Or only one variant? In the latter, then you'd need a new endpoint
4. How does the 10-point (or any other scale) convert back to the current 5-point scale? Presumably you would want the new scale to also be reflected on old clients. Floor down? Floor up? Round (100-point scale)?

[deluan]

1. Consistency. The existing averageRating is already float from 0 to 5:
2. Yep, it is required if we want to be able set the rating.
3. Yes, similar to how we send artist and all the new displayArtist. The old one is meant for older unmaintained clients
4. Open for suggestions :)

[kgarner7]

1. I'm not too keen on floats in general (even if it is for consistency), but only half steps feels worse (then you have to decide, is 1.5 1 or 2).
2. No comments there
3. I assume by that you mean a new endpoint to only set the new rating.
4. That depends ultimately on the implementation (and more broadly, how clients would display it). If it's functionally a larger range than 1-10, (so, 1-100, or infinite if a float), then round (with the exception that anything < 1, but greater than 0 is a 1). If it's functionally equivalent to a 1-10 scale, maybe ceiling?

[Tolriq]

IMO floats are bad if you want to express the 0...5 range with only half star support. As float should allow 1.1 2.3 and then showing as stars becomes a nightmare. (And json does not have a difference between float/double/...)
Some clients may display the whole 10 stars too.
For consistency on the client side and logic 0..10 is better choice for ratings with half stars.

For the conversion to old for 0..10 it's commonly ceiling in most app or other providers.