There are 7 tracks submitted, however, track 2da999a547356ae0cb95c4180726833d at least played 4 times while the client was offline, but only one was scrobbled. I expect all four times should be submitted.
In addition, according to Subsonic API document, scrobble supports time field to include the last play time, and Navidrome also supports it. It would be good if this information is synced as well.
Furthermore, Subsonic API document also mentions that multiple ids and times can be submitted in a single request, so you should be able to combine all the records into a single request. But this is a minor detail I don’t care too much.
…, unfortunately a few servers also bugs when sending multiple requests chained with the same item.
I’m curious how to have bugs on this… The worst case I can imagine is that they only increment once if multiple request on the same item comes in a short time? In that case, it shouldn’t be a big problem to do so.
But I guess it might not be a crazy idea to have an allowlist for server impls that do certain features correctly™ (when there is a clearly correct behavior as defined in the API). That way you only need to maintain a baseline behavior and an single optimized behavior guarded by allowed feature set of the given server impl at the given version. This is, to some extent, similar to SIMD optimizations guarded by CPU model.
That’s not how real world works (And as the tags says it’s already implemented for Navidrome).
Each function have differences and sometimes multiple versions. Like to sync I need support for empty queries to search3 endpoint there’s 3 different ways depending on servers to send that, and handle the fallback for servers that do not handle correctly that case.
And that also means that I need to fully test and maintain a compatibility matrix for every single functions and all the servers. Something that I absolutely not have time for.
As you can see : Explicit server name and version it was already a lot of work to have servers expose what they are. And there’s still the majority that do not expose their version yet. Meaning I can’t even build that compatibility matrix properly
So until the work is done with API extensions and servers proper handling of things, every variation is a support burden and time loss for every future changes to manage regressions.
you can have a feature set for each server
I support Emby / Jellyfin / Kodi / Plex / Android / Subsonic. That’s already 6 (8 actually as 3 modes for android) different set of features to maintain and evolve with their versions.
Adding 20 more for 20 different Subsonic servers is just not possible. Specially for edge cases.
Ah I didn’t realize that even the server name and version are not part of the official API, but that makes a lot of sense.
As long as it’s implemented for Navidrome, I’m happy for now
(If there are enough people care maybe there can eventually be a standard with an open test set developed to have implementations converge… but it’s probably just too hard with many of the projects with just a single maintainer doing it with labor of love.)