Squeezelight players frequently disconnect in mutiroom setup

Max2Play Home 2016 (en) Forums Max2Play as Squeezebox (Player / Server) Squeezelight players frequently disconnect in mutiroom setup

This topic contains 8 replies, has 2 voices, and was last updated by  marc premium 1 year, 11 months ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • 29. April 2019 at 20:17 #45171

    Dear all,

    I have a M2P multiroom setup with one server and six clients running for two years now. Occasionally I always experienced that clients got lost in the past, that is, they did not show up on the lms anymore and someteimes also were not connected to the network (routed by two meshed fritzboxes). In these cases the clients were inaccessible via the web interface and ssh and needed a reboot. Since I had SDcard write protect enabled I could safely power down/up the devices. After that, they were seen in the network as well as in lms. It only happened rarely and I did not give it a deeper look although it always was an annoyance and not very waf-freindly.

    Recently these client dropouts have been increased drastically. I did update the clients to the lates m2p version (starting with 2.47) and the lms to the latest 7.9.2 version but can not 100% route the problem to the updates. Now, usually 1-3 from the 6 clients drop-out from the lms connection. Some also disconnecct from the network completely. Even more weird, sometimes a clients drops-out from lms but still is visible and accessible in the network. The server logs do show the disconnect, usually logged by the ShareTunes plugin installed at the lms. But i do not have a clue what is going on at the clients. I have one „official“ squeeze device attached, the remote, and that one never gets lost hinting to the raspi m2p clients as the critical parts. As is, the whole multiroom setup is completely unusable for anyone in the household except myself.

    Any ideas what could cause this behavior?

    Here the setup:

    ## Server:
    Synology DS 1513+
    Logitech Media Server Version: 7.9.2 – 0018.1548605546
    Also running ShareTunes2 plugin

    ## Clients (all running licensed m2p version 2.48 and only Squeezelite):
    1. Raspberry A+ with HifiBerry DAC+
    2. Raspberry A+ with HifiBerry DAC+ Pro
    3. Raspberry A+ with HifiBerry Digi+
    4. Raspberry Zero W
    5. Raspberry Zero W
    6. Squeezebox Controller

    30. April 2019 at 12:26 #45182

    Hello marc,

    Is this issue different from your other post? Can I mark it as fixed?

    30. April 2019 at 16:21 #45192

    Dear Heiner,

    No, unfortunately it seems different. The other post can be closed after I replaced the faulty SDcard and this one client is now up and running again. I wanted to solve the latter first to make sure it wasn’t a cascading error, i.e., the one faulty client somehow messes up the connection of the other ones.

    This problem here is still there and the debugging is really hard.

    best

    2. Mai 2019 at 13:04 #45203

    Hello Marc,

    Please check to see if your server device has Stretch running and not jessie or wheezy, as those are legacy images. If possible burn a new image with our newest Stretch download and see if this changes the situation. You can back up your previous image with our image burner plugin.

    2. Mai 2019 at 16:59 #45219

    Dear Heiner,

    The Logitech Media Server Version: 7.9.2 – 0018.1548605546 is running on a Synology 1513+ NAS, which – as far as i know, uses a tailored linux not really related to any prominent linux distribution. The Synology delivered OS version (called DSM) is up-to-date to the latest available version „DSM 6.2.1-23824 Update 6“.

    Synology also provides an own version of the LMS, but it always is pretty outdated, i.e. it, still is based on 7.7.6-116 which has problems with several newer plugins. Hence I did install the newest version from the user pinkdot found here:

    https://forums.slimdevices.com/showthread.php?108960-Synology-7-9-2-packages

    Point is, this did run ok until I upgraded m2p to 2.47 and then 2.48

    best

    3. Mai 2019 at 10:00 #45227

    Okay, the same goes for the player units, which version do they run and can you check if they have jessie or wheezy whether a jump to Stretch might change anything?

    Also, can you try running a server on a Pi unit to see if the issue is the same to rule out the NAS a possible source of error?

    3. Mai 2019 at 10:08 #45230

    Dear Heiner,

    ok, I see. Am I right that
    1) updating the m2p version from the clients (currently 2.48) does not update the linux version installed?
    2) reinstalling m2p from the latest 2.48 image does include a new linux (now stretch)?

    About running the server on the pi, it will be possible although not exactly with the same setup since the music data then has to be shared via nfs from the syno. I’ll try this after the potential client update.

    best

    3. Mai 2019 at 11:17 #45234

    Hi marc,

    You can just try radio playback as a start, to make sure the issue is not a general one.

    You are right in your two statements.

    4. Mai 2019 at 16:29 #45260

    Hi Heiner,

    There is some more progress in debugging my music system problems. For breaking down the overall problem this is what I did first, also following your advise:

    1. Replaced the apparently faulty SDcard with one of the pi Zero clients (other thread in this forum), this one is now up and running again.
    2. Updated all clients to stretch, indeed, 3 clients were still on the old distribution.
    3. Removed all unnecessary plugins, the clients just run squeezelight.
    4. Enabled SDcard write protect plugin to avoid any damage during tests.
    5. Disabled the lms completely to first see how the clients behave just in the network without any lms server.
    6. Disabled the WLAN mesh and only had one of the two Fritz!Boxes serve the WLAN, this Fritz!Box box is connected via gigabit LAN to the Fritz!Box cable router and DHCP server. Worked like this for years.

    Result:

    – The two pi Zero W clients as well as the original squeeze controller are visible in the network and the m2p web interface of the pi Zero W clients is accessible.
    – The three pi A+ clients (with EDimax WLAN adapter, all purchased from M2P shop) appear after inserting the freshly prepared SDcard with latest m2p image but
    – the access point setup does not work, the password for the network is reported as invalid on connect.
    – The WPS setup takes a long time but after some 10 minutes all clients appear and can be set up similar to the pi Zero W clients (remove unnecessary plugins, enable write protect).
    – Then the A+ clients are visible on the network for some minutes but then suddenly disappear. The router (A Fritz!Box 6590 cable) does not report them anymore in the mesh interface and they can not be accessed either by the web interface or ssh or ping. They seem of the network. A reboot of the A+ clients triggers same behavior, they can be seen for a few minutes in the Fritz!Box network overview (although without any information on the quality of the connection as is normal for any other connected clients), but then disappear again and are inaccessible.

    So I don’t know if this is the reason but it seems highly unrealistic that exactly all the A+ clients create a problem, right? I think this has to be fixed first before I can go on and test the lms on one of the clients as you, Heiner, proposed. Any ideas on this behavior of the systems?

    • This reply was modified 1 year, 11 months ago by  marc. Reason: Forgot one step
Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.

Register here