Add ability to find rarely played albums to the REST API

[issuemover631]

Issue by neilweber
Sunday Nov 06, 2016 at 06:15 GMT
Originally opened as https://github.com/Libresonic/libresonic/issues/136

---

With a large library, it's easy to overlook some albums/songs. A libresonic app should give the user a way to surface rarely played albums. The REST API can currently return the most frequently played albums but there is no way to find the least played albums. This can be changed by adding a new type value of "infrequent" to the getAlbumList and getAlbumList2 methods.

With my recent clean Libresonic installation, many albums still have their play count as 0, so I'm thinking there should be some randomness added to avoid getting the exact same albums on each request. The SQL query I'm thinking of using is this:

select * from media_file
 where type = 'ALBUM' and present
 order by play_count, rand() asc
 limit 20

[issuemover631]

Comment by fxthomas
Sunday Nov 06, 2016 at 13:54 GMT

---

This is a great idea!

I'm concerned about one thing : how to expose this new API feature to clients safely? Ideally clients should be able to hide this feature from their UI if it is not supported by the server.

This is the same problem faced by #69, by the way, so we're really going to have to think about it at some point.

[issuemover631]

Comment by biconou
Sunday Nov 06, 2016 at 20:31 GMT

---

I agree. Could be a great feature.
Enhancing the REST api will emerge soon. And it leads to the following question. What mobile app will be the official one for libresonic. Personnaly, I vote for Ultrasonic. I use it and allready done PR.
See https://github.com/ogarcia/ultrasonic

[issuemover631]

Comment by fxthomas
Sunday Nov 06, 2016 at 21:37 GMT

---

A quick and easy way to add features to the API could be to indicate if the server supports extensions (and which) in the response from the ping API call. What do you think?

@biconou IMO there should be no need for an official app, especially given the number of existing options out there! I'm using DSub myself, how does Ultrasonic compare to it?

[issuemover631]

Comment by bajansen
Tuesday Nov 08, 2016 at 09:10 GMT

---

The subsonic API already return version information in each response. Clients already should perform a check to see what version of the REST API a server is running. If libresonic were to implement its own new API features, we could simply change the 'subsonic-response' tag to 'libresonic-response' (as already accidentally happened once) so app developers can distinguish libresonic-API version X from subsonic-API version X.

This decision should not be made lightly however. If we were to change the response tag, existing apps will have to be explicitly updated to support libresonic. If we choose to go this route, we should ship a setting to enable switching between the new libresonic API and the current subsonic API.

Some more information regarding the API can be found on subsonic's website: http://www.subsonic.org/pages/api.jsp

[issuemover631]

Comment by MichaelBechHansen
Monday Dec 12, 2016 at 21:02 GMT

---

One way to enable REST API compatibility would be to do like Ampache and Madsonic, and add a "type" field to all subsonic-response data.

For example:
{
"subsonic-response": {
"status": "failed",
"type": "ampache",
"error": {
"message": "Required parameter is missing.",
"code": 10
},
"version": "1.11.0"
}
}

Client apps can then check for the presence of type="libresonic", and enable whatever special support is available.
The subsonic REST API would be unchanged, except for the addition of "type" to all subsobic-response's.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.