Subsonic API not scrobbeling correct

[sebmuc99]

What version of Music Assistant has the issue?

2.3.3

What version of the Home Assistant Integration have you got installed?

2024.11.4

Have you tried everything in the Troubleshooting FAQ and reviewed the Open and Closed Issues and Discussions to resolve this yourself?

• Yes

The problem

Server is not scrobbeling correct to navidrome via subsonic API

Server is scrobbeling the play now action but never send the final submission event

https://www.subsonic.org/pages/api.jsp#scrobble

How to reproduce

play via subsonic

Music Providers

subsonic

Player Providers

sonos

Full log output

No response

Additional information

No response

What version of Home Assistant Core are your running

2024.11.0

What type of installation are you running?

Home Assistant OS

On what type of hardware are you running?

Raspberry Pi

[OzGav]

@khers

[khers]

I cannot reproduce this on Gonic. When the stream is opened, I scrobble with submission=False to report for now playing and when more than half of the song has played (or buffered to the speaker) I scrobble with submission=True.

The play counts in my Gonic instance look about right.

[OzGav]

@khers seems so many problems with Navidrome…?

[khers]

I think that has 3 probable causes in order of how likely I think they are:

1. Navidrome is the most popular Subsonic clone since all the Java implementations seem to loose steam (who can blame the devs, IMO Java beats the love of programming out of anyone, if MA was in Java I would not be here ;) ).
2. I use Gonic (Navidrome has no podcast support and consolidation of my podcasts into a place where I can move the streams between devices (without being spied on by the host) is important to me so I picked Gonic. But that means I wrote the provider to work around it's quirks or whinged at the Gonic dev to change things (he is awesome and super responsive so shout out there).
3. The Navidrome devs have a very different view of how to present media data from MA. Prior to working on this project I never thought too hard about all the complexity wrapped up in media metadata. I have come around to the thoughts and beliefs you and Marcel have on this and that model is very close to Gonic, but very different from Navidrome. This will mean that there are likely more rough edges with the integration.

All that said, I still want to try and support Navidrome but occasionally folks are going to have to report issues to the Navidrome devs because I am not a user of the project.

[OzGav]

So does the OP need to report this to the Navidrome project?

[khers]

If OP is certain that the scrobble call with submission=True is never being made then it is something I should investigate. But I added print statements around the async call (actually ensuring that the scrobble call is made, or that any async python request runs, is not as simple as stepping through with the debugger) so it was queued to run and I see play counts change on my server so I would be really surprised if it did not.

If play counts are not changing for OP first double check that you can scrobble something on your server with submission=True using https://github.com/khers/py-opensonic. I can help diagnose further if OP wants to investigate.

[OzGav]

@sebmuc99 please do some more testing as suggested above.

[FredHags]

@khers
I have done some "dirty" testing.
Running Navidrome v0.53.3
Using python requests with the Navidrome API
All done with Subsonic v1.16.1 standard API calls.

I run a loop checking "nowPlaying", then when the "id" of the song changes from the previous one I scrobble (submission=True) the "id" of the previous track.

The scrobble has a 100% success rate

I found out that you can't really rely on the media_player media_position since MA creates an endless stream to my Sonos speakers.

[khers]

@khers I have done some "dirty" testing. Running Navidrome v0.53.3 Using python requests with the Navidrome API All done with Subsonic v1.16.1 standard API calls.

Just being super pedantic here, the provider is an opensubsonic provider and tries to follow the opensubsonic api docs.

I run a loop checking "nowPlaying", then when the "id" of the song changes from the previous one I scrobble (submission=True) the "id" of the previous track.

The scrobble has a 100% success rate

https://github.com/music-assistant/server/blob/fe175c4fae9ea431c47c86c1841eee62f1d4b2fe/music_assistant/providers/opensubsonic/sonic_provider.py#L688

This is where we report for Now Playing. However, we are not going to monitor the subsonic api to know when this changes, when the user starts playing another track MA will call get_stream_details() again for the new track. However, according to the opensubsonic community (I can't find the exact discussion now, but will do some more digging) a play count should only be registered with more than half of the track was played. This means that the loop watching now playing or relying on future calls to get_stream_details() would record plays even if the track played for less than a second before the user skipped it. There is a lot of discussion about why the stream end point should not be used to trigger a play count here: opensubsonic/open-subsonic-api#22

I found out that you can't really rely on the media_player media_position since MA creates an endless stream to my Sonos speakers.

That is correct, unfortunately some players will report a full play back as soon as the track is cached on the speaker but that is not a thing I can address in the subsonic provider. We get as close as we can by registering a callback to happen when the stream is finished/changed here: https://github.com/music-assistant/server/blob/fe175c4fae9ea431c47c86c1841eee62f1d4b2fe/music_assistant/providers/opensubsonic/sonic_provider.py#L713

The on_streamed() method is invoked by the player controller when the stream is finished or changed and we get the number of seconds streamed to the player (this is where the really large stream buffer on sonos devices can bite us as it looks like the track completed right after starting).

I will write up a patch that adds more debug logging around these things, but the real interesting thing would be some indication that the scrobble call made from on_streamed() is not executed.