Add clarifiaction on result of scrobble by cquike · Pull Request #202 · opensubsonic/open-subsonic-api

cquike · 2026-02-04T22:11:00Z

This PR adds the clarification discussed in #201:

If any of the id's in the scrobble is invalid the result is error code70.
If any of the id's in the scrobble is invalid no scrobbled should be even for the valid id's.

netlify · 2026-02-04T22:11:07Z

✅ Deploy Preview for opensubsonic ready!

Name	Link
🔨 Latest commit	`f677b86`
🔍 Latest deploy log	https://app.netlify.com/projects/opensubsonic/deploys/6984b334a124680008af34f1
😎 Deploy Preview	https://deploy-preview-202--opensubsonic.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

Implements OpenSubsonic API clarification from PR #202: the scrobble endpoint now validates all media file IDs before processing and returns error code 70 (data not found) if any ID is invalid. This ensures the entire operation fails atomically - no scrobbles are submitted when any ID in the batch is invalid, matching the OpenSubsonic specification. Changes include updating MediaFileRepository.Exists() to accept variadic IDs for efficient batch validation via a single COUNT query. See: opensubsonic/open-subsonic-api#202 Signed-off-by: Deluan <deluan@navidrome.org>

Tolriq · 2026-02-05T07:31:42Z

Unfortunately that's not how it works :) We can't just clarify things if all the servers are not on page else the docs says X and the servers do Y and this breaks the purpose of OpenSubsonic.

If you can get all subsonic servers onboard to actually do that before merging this then why not.
Else it's best to write it as the server should do that with a note that the client should check actual implementation.

deluan · 2026-02-05T11:05:14Z

~~I'm onboard with it (Navidrome). That totally make sense, even though I'm not doing it atm. Just waiting for this to be approved to merge the fix: navidrome/navidrome#4984~~

EDIT: As pointed out below, I actually think that processing the valid scrobbles, and silently ignoring the failing ones is a simpler and better approach.

paulijar · 2026-02-05T16:14:08Z

I'm willing to update Nextcloud Music to follow this specification.

epoupon · 2026-02-06T13:38:18Z

From the point of view of a client who has stored offline dozens of scrobbles.
Does that mean that if a track has been removed, they won’t be able to submit anything?
So this would end up forcing clients to always submit scrobbles one by one? (in reality the client probably doesn’t care much about knowing that the track is no longer there, it’s more of a best-effort thing)

Tolriq · 2026-02-06T14:00:15Z

In my case I always send 1 by 1 to be sure the data is properly synced when back online, and rely on the error 70 to stop trying as I know the track is no more on the server and not a temporary issue that I'll retry later.

deluan · 2026-02-06T14:00:20Z

So this would end up forcing clients to always submit scrobbles one by one?

I think this is up to the client to decide. If I was implementing it, I'd do:

Try to send the batch first, if it returns success, great!
If not success, fallback to sending it one by one, skip/log/notify the ones that resulted in error

Thinking more about this, maybe the simpler implementation of always return success make sense: If the client is well implemented, this should only happen when the music file is gone, and in that case any errors could be safely ignored.

MichaelBechHansen · 2026-02-06T14:41:01Z

play:Sub chiming in here:
This seems like a case that will only happen when the media is gone from the server,
which means there is not much that can be done to remedy anything.

Failing otherwise good scrobbles and requiring a fallback to scrobbling 1 by 1 will mean more complex/errorprone implementation with little gains to show for it.

I'm in the pragmatic camp here, and believe that succeeding the scrobbles that are ok, while silently failing the others are the way to go in this case.

MichaelBechHansen · 2026-02-06T15:00:46Z

Maybe the clarification should be along the lines of:

individual scrobble requests may fail with error 70 when media is no longer available
multi-scrobble requests will succeed when at least one scrobble is accepted at the server.
Servers will only fail a multi-scrobble request when all scrobbles are failed.

paulijar · 2026-02-06T21:51:37Z

Maybe the clarification should be along the lines of:

individual scrobble requests may fail with error 70 when media is no longer available

multi-scrobble requests will succeed when at least one scrobble is accepted at the server.

Servers will only fail a multi-scrobble request when all scrobbles are failed.

If going down this road, I would rather just specify

the request will fail with 70 if all the given id values are invalid
the request will succeed if there is one or more valid id values; any invalid values get silently ignored

There's really no reason to separate the single/multi cases here because the single-id is just a one-item-list and already sufficiently handled by the generic rules.

lachlan-00 · 2026-02-08T03:32:15Z

Maybe the clarification should be along the lines of:

individual scrobble requests may fail with error 70 when media is no longer available

multi-scrobble requests will succeed when at least one scrobble is accepted at the server.

Servers will only fail a multi-scrobble request when all scrobbles are failed.

If going down this road, I would rather just specify
* the request will fail with 70 if all the given `id` values are invalid

* the request will succeed if there is one or more valid `id` values; any invalid values get silently ignored
There's really no reason to separate the single/multi cases here because the single-id is just a one-item-list and already sufficiently handled by the generic rules.

This is the way i would do it. right now i ignore missing items entirely so it's always successful which is a throwback to last.fm using title, artist, album for submission. technically it was submitted successfully, just didn't find anything.

Most submissions will be singles and this is submitted by ID so a fail on all submitted would be the way.

There are a few things like this in the API that have a subsonic way that i'm not always aware of so this is a good thing to do.

lachlan-00 · 2026-02-12T11:44:27Z

content/en/docs/Endpoints/scrobble.md

 {{< /tab >}}
 {{< /tabpane >}}
+
+If any `id` is invalid the result is an empty [`subsonic-response`](../../responses/subsonic-response) with error code 70 "The requested data was not found". Note that in this case the whole request has failed and no scrobbling should be performed for those `id` which are valid.


"If all id values are invalid" and you would get this pull through

kgarner7 · 2026-03-21T18:33:48Z

Hi there, what is happening with this PR?

deluan mentioned this pull request Feb 4, 2026

fix(subsonic): return error 70 when scrobble contains invalid IDs navidrome/navidrome#4984

Draft

10 tasks

Add clarifiaction on result of scrobble

f677b86

cquike force-pushed the scrobble_result_clarification branch from 39330c1 to f677b86 Compare February 5, 2026 15:11

deluan requested a review from a team February 6, 2026 12:23

lachlan-00 requested changes Feb 12, 2026

View reviewed changes

Conversation

cquike commented Feb 4, 2026

Uh oh!

netlify bot commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for opensubsonic ready!

Uh oh!

Tolriq commented Feb 5, 2026

Uh oh!

deluan commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paulijar commented Feb 5, 2026

Uh oh!

epoupon commented Feb 6, 2026

Uh oh!

Tolriq commented Feb 6, 2026

Uh oh!

deluan commented Feb 6, 2026

Uh oh!

MichaelBechHansen commented Feb 6, 2026

Uh oh!

MichaelBechHansen commented Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

paulijar commented Feb 6, 2026

Uh oh!

lachlan-00 commented Feb 8, 2026

Uh oh!

lachlan-00 Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

kgarner7 commented Mar 21, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

netlify bot commented Feb 4, 2026 •

edited

Loading

deluan commented Feb 5, 2026 •

edited

Loading

MichaelBechHansen commented Feb 6, 2026 •

edited

Loading