search

FoxxMD / multi-scrobbler

Scrobble plays from multiple sources to multiple clients
https://foxxmd.github.io/multi-scrobbler
MIT License
346 stars 16 forks source link

Queued scrobbles are lost when Multi Scrobbler docker container needs to be restarted - possible to store queue outside container? #159

Closed infinitejones closed 3 months ago

infinitejones commented 3 months ago

Describe the bug Running Multi-Scrobbler in a Docker container, using Navidrome as a source and Last.FM and Listenbrainz as clients.

Several times now I've checked multi-scrobbler and realised that both clients need re-authenticating. It's not clear why but it's not possible to re-authenticate with restarting the multi-scrobbler docker container (which I do with docker-compose down && docker compose up -d) - when I try clicking on the re-start/re-authenticate links on the clients' "tiles", nothing happens.

Restarting the container enables me to re-authenticate just fine, but in the process all queued scrobbles are lost when the contaier comes back up. I've just lost six days' worth of scrobbles as a result of this.

To Reproduce

  1. Run the app in a docker container, connect a source but no clients, observe queued scrobbles
  2. Restart the container via docker compose down && docker compose up -d
  3. Observe queued scrobbles are no longer in queue when app comes back up

Expected behavior At step 3 above, queued scrobbles should be retained in queue ready for scrobbling when clients are re-connected.

Possible solution

Enable storing queued scrobbles outside of the container in a mounted directory, like /config is.

Versions (please complete the following information): Provide version information for any related sources/clients.

FoxxMD commented 3 months ago

Persisting queued scrobbles may be a future plan but for your issue i'd prefer to determine why you are having issues with restart/reauth in-app.

Listenbrainz does not require user-interaction to authenticate and does not have a re-authenticate link. In any case clicking "restart" on either or re-auth on LFM should produce some logging even if it there is a bug preventing it from completing correctly. I cannot reproduce your issues locally so you will need to include a sample of logs when this issues occurs for you.

If clicking the links does not produce any logs you will need to open devtools for your browser (instructions for chrome or firefox) and copy-paste any errors you see in the Console pane when trying to interact with the links. Any context from the Network pane would also be helpful.

If you can reproduce logs consistently, now, please provide as much information as possible.

Otherwise, you can log to file only warning/error logs which should be quiet enough to capture any issues that occur even over days/weeks of MS running. You will need to include a file-based configuration for MS to enable this. Add (or modify) /config/config.json:

{
 // ...the rest of your config, if any

  "logging": {
    "level": "debug",
    "file": "warn"
  }
}

then restart MS.

infinitejones commented 3 months ago

Sure thing, makes sense, thanks. I'll activate the logging in config.json and then I'll need to wait until it happens again. It's happened a couple of times but I can't reproduce at will.

When I have the logs, do you want me to open a new issue? Since it won't be addressing exactly the same issue that I've raised in this one.