Authentication test failed due to a network issue - requires Docker container restart to resolve, losing queued scrobbles #160
Comments
|
Thanks for the detailed writeup! These logs are exactly what I need. This may be related to #126 and #134 (comment) Can you try using the |
|
No worries - thanks for Multi-scrobbler! I've pulled the Debian image and re-started the container. If/when it fails again I'll post the same detail again here. |
|
Following up on this - the container's been running with the Debian image since my last comment, with no problems at all. I occasionally see timeout errors for Listenbrainz in the log but I think that's the Listenbrainz API rather than the Multi Scrobbler. They don't prevent tracks being scrobbled correctly. (None visible in the log currently - I can post some in another issue if I see any again, if you want...?) |
|
That's likely the the LZ API. Glad the debian image has resolved the issue for you. I may be switching to use that image as the default in the near future since alpine seems to still have unresolved dns issues. |
|
OK so after an unplanned container restart (due to a power cut), this happened again. This is using the Debian container. Last.fm and Listenbrainz client tiles had ended up in the same state as my original screenshot and clicking the Start buttons didn't re-connect them. (Logs below.) Connected again automatically after On attempting to re-auth with Last.fm, the callback URL ended up on a page saying On attempting to re-start Last.fm: On attempting to re-start Listenbrainz: |
|
Thanks for the logs. Both of these errors are related to (upstream of the container) network connectivity. The debian image has solved this issue when it's intermittent but consistent but your issue seems to be rarer than those. I'm not ruling out it being an image issue but the fact that
|
|
Aaaah OK - yes, I run pi-hole on another machine - so I suspect it might be as simple as the container coming back up and attempting to connect after the power cut, before the pi-hole machine was back up, and/or before my modem/router had had chance to re-connect to the Internet. I just did a "controlled" power cut/restart and the same thing happened. Until then, the Debian container had run flawlessly for over a week. Thank you! |
|
I'll leave this open for now, just in case, and check back in in a week or so to see if the debian image is still working as expected for you. EDIT: Switched to using debian for base image in v0.8.0. You can (should) switch back to using |
|
@infinitejones how has the container stability been for you this last week? |
|
All good, no problems at all. This is using |
Describe the bug
Original Issues: #159
At times, Multi-scrobbler loses the ability to connect to clients, and clicking the Start button on their tiles does not re-start them. Restarting the connection seems to require a restart of the Docker container, which has a side effect of losing queued scrobbles.
Screenshot
Clicking Start does not re-start the connection. Clicking re-authenticate for Last.fm does start the re-authentication workflow.
Expected behavior
I'd like to be able to re-connect to the clients without needing to restart the Docker container.
Logs
If possible reproduce the issue with debug logging ON
Versions (please complete the following information):
Additional context
docker compose exec -it multi-scrobbler /bin/bash) I can ping the Navidrome container and I can ping IP addresses, eg. 8.8.8.8 - but I cannot ping domain names, eg. www.google.comdocker compose down && docker compose up -d, connectivity to both clients is resolved - with no additional changes to the server's internet connection or the docker network for my stack.The text was updated successfully, but these errors were encountered: