EDIT: I forgot to send the log the first time i posted, and now i can’t upload it on an edit
I use Symfonium with Navidrome. And today i took a look inside Navidrome’s DB and noticed that some songs had scrobbles with the same timestamp.
Device type
Phone
Media provider
Navidrome
Steps to reproduce
To reproduce the issue, i downloaded the songs in the screenshot and played them while disconnected from the internet, and consequently from the server. Then i did some tests.
Here’s what test each row in the screenshot represents:
1st: Me listening to the same song 9 times
2nd: Me playing 3 times, waiting one minute (Longer than the song’s duration) and playing 3 times again (Note the duplicated timestamps weren’t divided into 2)
3rd/4th: 2x Shipwrecks and treasure, 2x Where hidden magic sleeps and 2x Shipwrecks and treasure again (Noticed how these weren’t split into 3 either)
5th: Played it for 3 times and noticed the timestamp matched exactly with the time when i finished playing for the 3rd time.
Additional information
Conclusion
This is my theory:
When Symfonium has no access to the server, it saves all song scrobbles on a buffer. When a song inside the buffer is played >1 times, the scrobble count for that song is increased and the timestamp is overwritten with the new one. When Symfonium gets a connection to the server, it sends all scrobbles inside the buffer count times, all with the same timestamp, then clears the buffer.
Fix
The buffer should contain individual scrobbles, meaning instead of grouping scrobbles by song and overwriting the timestamp repeatedly, it should save every scrobble as an independent item.
About the logfile
I didn’t know sending the logfile was required, so in the log, i did this:
Disconnected from the internet
Played “Shipwrecks and Treasure” 3 times (Not the same 3 in the screenshot),
Connected to the internet and my Navidrome server.
I confirmed the timestamp on all 3 scrobbles were the same
Yes this is by design and due to how things works in the API of most media centers. The main need is to ensure consistency in all cases for the playcounts and lastplayed value across all cases, not perfect offline scrobbling at the exact seconds.
Hey @Tolriq , just my 2 cents: For proper offline scrobbling, the client needs to send the IDs paired with timestamps (1 ID => 1 timestamp, 6 IDs => 6 timestamps), so the server can relay the scrobbles to external services (Last.fm / LB). In case of repeated scrobbles (song playing in repeat), if we don’t have the timestamp for each play, servers would send to the same timestamp for all instances, which is refused by Last.fm ofc. This means the user loses scrobbles.
Even in cases without repeated scrobbles, if all scrobbles are sent without a timestamp, the server cannot “fabricate” it. And if we send the same timestamp for all scrobbles, Last.fm and LB also rejects them (you can’t listen to a multiple songs at the same time)
Can’t you keep the individual timestamps in the offline scrobble buffer? That’s how other clients that support offline scrobbling works.
We already talked about that, the timestamps are changed by 1 ms on replay to ensure it works properly on your side (and it did when we talked about it, maybe it changed and now 1ms is not enough ?). The only ‘problem’ is that for multiple offline playback the date are not 100% accurate as all near the time of the last played one.
I have no short plan to rebuild the whole system, as it impacts all providers and everything for a small and rare annoyance.
Yeah, I remember, but seems that Last.fm is rejecting times too close.
And this is not a small rare situation: it affects all offline scrobbles, as they are sent with basically the same timestamp to Last.fm.
Also, it does not really reflect the users offline usage: If they keep Symfonium in offline for a few days, when they get back to online, it would send all scrobbles in the same day, not at the actual time they happened.
Anyway, these are my 2 cents. There’s nothing much I can help on the server side.
No you misunderstood, each song send the proper timestamp of it’s last playback so for a given song if it’s played multiple time it will send the last time then last time +1ms, … But there’s never 2 songs with the same one.
I see no reason to not scrobble the songs with the right timestamps. (aside from potential limitations from Symfonium’s design, ofc) It’s the objectively correct way to scrobble.
But either way, a lot of people, including me, take their listening history very seriously. As Deluan mentioned, this breaks last.fm scrobbling, which is crucial to many. I’ve seen a lot of bug reports here relating to scrobbling, which proves people do care. And i’d bet there are many others that noticed this on last.fm (or other services), got frustated, but didn’t bother to report it.
Also, what if the person went on a trip and didn’t have access to their server for a long period of time? They would potentially lose hundreds of scrobbles to last.fm (or other services). I’d be really pissed.
Might not be relevant, but i’m working on a project to analyse Navidrome scrobble history, like last.fm but for Navidrome specifically, and having the correct timestamps on Navidrome’s side is important for accurate analysis..
If scrobbling with correct timestamps breaks most media servers out there, is there no way to make an exception for Navidrome or other media servers?
99% of the songs have the correct scrobling. And there’s already exceptions for Navidrome as it’s one of non broken Subsonic servers handling the times properly.
The only limitation is repeated same song offline. The app cares about last played and playcounts and they are the thing it optimize and ensure works in all cases for all servers. No server expose a full playback history in it’s API and scrobble are mostly a side effect in most servers.
Changing how this works in Symfonium side is a lot of work due to the multiple dozens of servers involved with such changes and all the side effects on the actual playcounts and lastplayed that needs to work and are much more important for the vast majority of users.
I’ll redo a quick audit of all servers but I’m really not sure it’s worth the risk.
The main issue being proper preservation of the last played when setting resume points but not increasing playcounts for example and a couple of other edges cases.
@deluan What do you think about expanding scrobble endpoint so that submission=false but a time is passed means you update the last played but not the playcount ?
What is the use case? I’m not sure if this is a good idea, some clients may send multiple submission=false while playing the song (even though they shouldn’t). Currently this is harmless, it does not affect the data, But making it change the last player, could make the data wrong, it would make the server lose when the track actually started playing. submission=false is a nowPlaying signal, it should not change any data, IMO.
Depending on what you want to accomplish, we can adjust the playbackReport for this. AFAIK, no one implemented it yet.
Re: timestamps for offline scrobbling: Sending multiple IDs with their correct timestamps is specified in the OG Subsonic API, and it is the observable behaviour of OG Subsonic. So, IMHO, if implementing it the right way breaks other Subsonic servers, they have to fix it.
You already know that’s it’s not possible And I also support many many non Subsonic servers.
The use case is user control People have control about when resume point are set, when playcounts are set and when last played is set (when setting a resume point or when marking as played).
There’s currently no API to update the last played value for proper sorts without increasing the playcounts. For Navidrome setting a bookmark (resume point) does not update it and it causes quite a few problems as values on Symfonium does not match what Navidrome will return on the next sync.
So the need is to have a way to update the last played of songs to ensure consistency with client states.
I’d argue that we can’t penalize users of the most used servers to please a few users from a couple of ill-behaved servers. But that’s just my opinion
For Navidrome setting a bookmark (resume point) does not update it and it causes quite a few problems as values on Symfonium does not match what Navidrome will return on the next sync.
AFAIK, setting a bookmark should not update last played, right?
Anyway, I think this is a good candidate to amend in the playbackReport extension. Do you know if it is already implemented by any server?
It’s not about pleasing, it’s about controling the amount of support I get. There’s only a very finite time for support.
It depends on what they are used for But yes probably undefined for music.
No one have done it yet, but I don’t think it fits as it needs to handled outside of any automatic server side, so would introduce a third concept to that end point. I have no idea how to make that clear and logical while sticking to what’s already there.
I think the best solution here is to change the scrobbling logic depending on the media server so that broken servers get the broken scrobbles, and based/GOATed servers like Navidrome get the proper ones.
Keeping track of which servers behave is a lot of work though, so i suggest a toggle (media server wise) to switch the two scrobbling behaviours, then the user can take care of the rest.
And I also support many many non Subsonic servers.
People have control about when resume point are set, when playcounts are set and when last played is set (when setting a resume point or when marking as played).