[API Request] Control / stream scrobling action #22
Replies: 6 comments 11 replies
-
This is interesting - it almost needs the server to interrogate the user agent to know when to increment the play count. Otherwise you'll never get any play counts if the client doesn't implement the newer API. |
Beta Was this translation helpful? Give feedback.
-
I 100% vote for this. The stream endpoint is annoying as hell especially as a dsub user. I have an option in ampache to ignore/allow scrobble on stream so it could be retooled to enable for older clients. |
Beta Was this translation helpful? Give feedback.
-
Ok so there was quite a few request this is nice, now we need to figure out the voting system and organization to start building on those requests. As a start since this is the most upped request and the simplest one since everyone seems OK with it, let's try to define the voting and validation process. @opensubsonic/servers @opensubsonic/clients :) For the vote I propose to use reactions as it's easy to count and see who vote. 👎 ⛔ would be a negative vote. For the rest it's up for debate. I suppose we should have 2 "rules"
|
Beta Was this translation helpful? Give feedback.
-
This is more a clarification than anything else the original subsonic and all direct forks recorded a play on request to the stream end point. The documentation for the scrobble endpoint is not clear and the behaviour of the stream endpoint is not noted in the API doc though so confusion isn’t a surprise. Newer servers which were not just direct forks (ie navidrome) choose to use the scrobble end point to record plays. I remember I had to update substreamer for this use case. Assuming we start at a new API version (say 2.0) for the first round of changes it’s our chance to create some clearer updated docs and note new endpoints or changes each version. We could actually use proper semantic versioning which would be nice… It would be great to get some of the non-breaking / smaller updates into a first version so we can get it implemented across all our platforms and a first release out, ironing out the process and showing users we are on top of things :) |
Beta Was this translation helpful? Give feedback.
-
i have seen a lot of clients that have a "scrobble to lastfm (if supported by server)" checkbox. which is unchecked by default. does this mean that we wont ever get playcount data if they don't check the box? imagine people without a lastfm account wouldn't think to check it |
Beta Was this translation helpful? Give feedback.
-
To make this happen I think we need to extend stream or mandate use of download. In ampache I have a cache parameter (e.g. cache=1) because dsub doesn't use the download method Download isn't a stream so clients should be using that to avoid a stream playcount. |
Beta Was this translation helpful? Give feedback.
-
Type of change
API Clarification
Proposal description
IMO this is an API clarification but it can also be a API change depending on the feedback of current servers.
While this is not officially documented some servers currently handle an access to
stream
as a playcount.This is wrong because it can be just used to play 1 sec of content, or used to download an offline media.
Since this is not documented this can also trigger duplicate playcount increase when clients properly send a scrobble after.
TL;DR: OpenSubsonic servers should not increase playcount on
stream
access and rely on thescrobble
api that is meant for that.Backward compatibility impact
Depends on current servers and client assumption.
Backward compatibility
API details
N/A
Security impacts
N/A
Potential issues
No response
Alternative solutions
The alternative solution is to add a new parameter to
stream
so that clients can specifically opt out of that mode and control manually viascrobble
endpointBeta Was this translation helpful? Give feedback.
All reactions