Thanks for the contribution! This is a good start.

I've added some limiters to prevent API spamming and made now playing user-configurable via options in the client

[
  {
    "name": "myLastFmClient",
    "enable": true,
    "configureAs": "client",
    "data": {
      "apiKey": "a89cba1569901a0671d5a9875fed4be1",
      "secret": "ec42e09d5ae0ee0f0816ca151008412a",
      "redirectUri": "http://localhost:9078/lastfm/callback"
    },
    "options": {
      "nowPlaying": false
    }
  }
]

It defaults to true.

Last thing that is needed is to address reporting Now Playing when multiple Sources have Players at the same time. My plan is to

• Aggregate playerUpdate events, pushed by playingNow, into a list on the AbstractScrobbleClient
• Implement ToadScheduler in AbstractScrobbleClient
  • Use a SimpleIntervalJob every 5 seconds to sort and filter list of updates based on either (default) alphabetical order of source names or use a user-defined order
  • Pick the first-sorted Source and then the latest update to return
• Use the sorted/filtered update to report Now Playing

We're not-so-familiar with the codebase still, but is there a way to uniquely identify player instances? If so, perhaps we can just use a map of SomePlayerId->PlayObject where we only update the value if the received update is newer than stored.
And instead of sorting the source names when updating Now Playing, just set the user-defined order to default to a list of existing, configured sources, in alphabetical order, if the user-defined order is undefined or []; and then simply loop through the list to find the first value that's present in the Now Playing status map.

It seems less complicated this way to us, let us know what you think

There is a unique player id generated from a PlayPlatformId (device + user) parsed from Play data. However the id is not user friendly, deterministic, or easily predictable -- IE spotify players identify using unique device strings but subsonic players identify using an incrementing numeric value based on how many concurrent players are already playing.

default to a list of existing, configured sources

Scrobble clients are not aware of what Sources are already configured, that responsibility is left up to ScrobbleClients.ts to filter based on scrobbleTo. This is why sorting on-the-fly is necessary. The reasoning behind the scheduled aggregation is that, since the Client doesn't know what Sources are available, it will make a runtime decision as to which has the highest priority based on what updates (sources) are available within the scheduled window.

@msparkles queue/scheduling/filter/sort is all implemented and the image foxxmd/multi-scrobbler:pr-316 should work for the last.fm use case, please test it out and let me know if there are any problems.

Still to-do:

• Listenbrainz implementation of doPlayingNow
• Minimal tests
• Document user config for nowPlaying

We'll test it out today ASAP.

Listenbrainz implementation of doPlayingNow

Should this be a separate PR? We can't test this ourselves since we don't use Listenbrainz.

Yeah I can add LZ implementation after merging.

@msparkles Please update to the latest foxxmd/multi-scrobbler:pr-316 image. Fixed some bugs discovered by tests.

@FoxxMD We're running the program via systemd, so we can't test the image per-se, but it works on the latest commit!

📦 A new release has been made for this pull request.

To play around with this PR, pull an image:

• foxxmd/multi-scrobbler:pr-316

Images are available for x86_64 and ARM64.

Latest commit: f885726

Docs are now updated and I implemented an additional ENV NOW_PLAYING=true (or false) to allow globally enabling/disabling now playing, when it isn't explicitly set in a client file config. The default is true.

Thanks for contributions and feedback. This is available in the master branch and edge docker tag now.