Scrobble plays from multiple sources to multiple clients
Support for notifying of scrobbles and errors via Apprise using an apprise-api server. See the docs for configuration.
The API and Dashboard can now be disabled. This can be useful for users who do not want a point of ingress in to MS on insecure networks.
See the majority of changes in the RC1 release
This is a pre-release that makes some major changes to dependency versions and internal(ish) tooling but no changes to configuration or primary functionality.
Replaced logging solution, which was based on an outdated (100's of commits behind) fork of winston, with @foxxmd/logging:
2024-03-21 16:18:35.520 -0400
scrobble-2024-03-22.log.X to scrobble-2024-03-22.X.log
To support simpler testing with Mocha the minimum node version required for development and testing has been bumped from v18.16.0 to v18.19.1 in order to enable --import usage.
Several bug fixes and general improvements are also included in this release. Specifically, improvements for subsonic sources and duplicate scrobble matching. See the full changelog below for all changes.
Prior to 0.5.0 MS let you see "recently played" directly returned from a Source's upstream API (for those that have it IE spotify, lastfm, listenbrainz...) This was useful for determining if the Source's API was "behind" what had actually been played -- for instance sometimes Spotify's "recently played" can be delayed by minutes/hours which could result in backlogging not returning what you "know" was played more recently.
This is entirely a convenience for the user, rather than new functionality for MS, but had been missing as a feature. This release returns this feature to the frontend.
For some sources (Lastfm, Listenbrainz) MS always uses the recently played data as the source-of-truth for scrobbling to your clients, rather than MS's "player". This is due to information returned for "now playing" for these sources being less accurate than recently played data. This has functionally not changed but this discrepancy is now more clearly presented to the user in the UI via a ? tooltip icon.
I have rewritten parts of the third-party library providing google cast (chromecast) functionality to be more stable and less prone to crashing the entire MS application. Reconnecting events should now be more reliable as well.
An issue causing requests to Last.fm to hang forever has been fixed and will now cause the request to timeout in a reasonable amount of time instead of freeze up MS #134
A bug causing scrobbles with non-english character-symbols to potentially not match existing scrobbles from client has been fixed. #121
An alternative debian-based docker image is now provided for x86/x64 host architectures through a *-debian flavored tag. This image may be used as a workaround if you experience sporadic networking issues with the regular docker images. #126
Support for Google Cast devices as Sources. This is particularly exciting because music platforms that do not have an API for exposing user Now Playing info (Pandora, Tidal, MixCloud, Soundcloud) can now be monitored if you play them through a Google Cast device. Additionally, since the Cast platform exposes generic Now Playing information virtually any app that plays music through Casting can now be monitored by MS.
This is no functional change for end-users. This is an internal/development refactor but brings with it many benefits:
The only visible changes are:
API_PORT anymore -- use PORT for both dev/prod now.All sources have been refactored to have more granular init stages:
If any stage fails more descriptive errors are logged for the failure and the stage it failed at is also described, giving users more insight into why a source failed to start as well as improving debugging.
App-crashing errors should now be logged before the app crashes. The easiest way to capture these logs is to set file logging to warn log level so they are stored to file. In your file-based config.json`:
{
"logging": {
"level": "debug",
"file": "warn"
}
// ...
}
A future release will include a migration from the current spotify api library to the official spotify web sdk. The information stored for Spotify credentials in releases prior to 0.6.4 is insufficient and will require reauthentication by the user if, for example, the user upgrades directly from 0.6.2 -> 0.6.5+.
0.6.4 will store all required credential information needed for future releases. Simply upgrade to this version and wait a few hours for Spotify credentials to be refreshed.
MS now tracks Album Artists and correctly scrobbles this info if the client supports it.
For polling sources that report track duration (Spotify), MS will now decrease polling interval near the beginning and end of the track in order to get more accurate "listened duration" and track start timestamp. NOTE: Spotify's Automix feature may interfere with this.
The Webscrobbler browser extension has been added as a source using its native webhooks behavior.
Quietly implemented in 0.6.0, MS has two new control structures for making scrobbling more resilient to offline clients and network issues:
When a Source player state is detected a "Now Playing" player will render in the Source card showing how MS tracks plays for scrobbling.
The UI has been reworked to reduce whitespace, compact the layout, use headers more effectively, and improve wording/visualization.
Recently played tracks are now linked to their source (Spotify, Maloja) if MS can parse them.
A suite of tests have been added to test core backend functionality. These tests helped surface multiple bugs that should, now fixed, reduce duplicate scrobbles and improve consistency for all sources/clients.
options property use "scrobbleBacklog": false to disable backlogging on startup"enable": false" to disable using that configIf you are using Portainer to manage containers you should remove all non-MS related ENVs from the container template before pulling the latest image.
Previously, the default settings for scrobbling a track specified to scrobble if it was played for more than 30 seconds. This has been increased to:
If you have scrobbleThresholds set in config.json or in individual source configs this does not affect you.
Due to the above change the default polling interval for sources have been adjusted like so:
This provides more accurate "listened to" recording and, generally, better source tracking resolution. This should not adversely affect your usage of each provider other than increasing bandwidth a little. These default settings can be overridden using the interval and maxInterval properties in individual source configs.
MS now has a scheduled "heartbeat" that runs every 20 minutes. It's purpose, for now, is to is start (or restart) sources that have stopped due to upstream issues. The use-case for a Source is:
The heartbeat tasks will automatically try to restart polling for this Source so MS can recover from an upstream API communication error without user intervention.