Scrobbles should happen earlier, not at the end of the track playback

[csaavedra]

This is similar to what I explained in the last.fm plugin (jesseward/jellyfin-plugin-lastfm#50). Scrobbles should happen earlier, preferably as soon as the condition for scrobble has been met and not rely on the stop event from the player as it's known to have issues. More details in the other issue, including an idea of how to do it.

[lyarenei]

Scrobbles should happen earlier, preferably as soon as the condition for scrobble has been met

With reading the issue on the last.fm plugin, I have to disagree. At no point in both ListenBrainz or last.fm documentation is such thing specified. Both platforms just specify the conditions which must be met for sending the data, but everything else is left up to the client.

ListenBrainz documentation only specifies the conditions:

Listens should be submitted for tracks when the user has listened to half the track or 4 minutes of the track, whichever is lower. If the user hasn’t listened to 4 minutes or half the track, it doesn’t fully count as a listen and should not be submitted.

— https://listenbrainz.readthedocs.io/en/latest/users/api/core.html#post--1-submit-listens

And last.fm documentation you linked in the lastfm plugin issue gives similar conditions:

A track should only be scrobbled when the following conditions have been met:

• The track must be longer than 30 seconds.
• And the track has been played for at least half its duration, or for 4 minutes (whichever >occurs earlier.)

Last.fm documentation then goes on explicitly mentioning that once the conditions have been met, the scrobble can be sent at any time:

As soon as these conditions have been met, the scrobble request may be sent at any time. It is often most convenient to send a scrobble request when a track has finished playing.

— https://www.last.fm/api/scrobbling#when-is-a-scrobble-a-scrobble

While as soon as the condition for scrobble has been met is technically at any time, I do not see any reason to implement such feature as:

1. Both platform APIs allow specifying timestamps for the scrobbles/listens => you always have accurate data.
2. If you need something more immediate, both platforms have 'Now Playing' => there's really no need to send scrobbles/listens ASAP.

So, basically, unless I'm missing something, developing such feature would cost too much with no benefits. Of course, you can always try to prove otherwise or just implement this feature yourself.

Now, for the issues with 3rd party clients not reporting playback event, this has been worked around in this plugin with introduction of alternative detection mode (documented here) - as long as the client marks items as played on the server.

[lyarenei]

Closing due to inactivity.