Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 2 of 2
  1. #1

    Why does networking go south?

    First thing, a piCorePlayer/rPi restart "fixed" this problem.

    I'm curious if the more knowledgeable on this forum have an explanation for why a system restart fixed the problem (as aggravating as that is). I'm a 30-year IT guy (though not in advanced networks) and I'm baffled.

    Scenario - SOME network streams stop working. Logging shows an error like:

    "Error: Can't connect to remote server to retrieve playlist for, [URL]: Connect timed out: Bad file descriptor."

    I could copy that URL from the log file successfully connect to the URL using wget from an SSH prompt on the rPi at the same time that LMS was saying it could not connect. Logically, networking on the LMS rPi system MUST BE working (or, well, wget would fail) and the remote HOST also be working (or, again, wget would fail). So whatever is awry, it's not the remote host (or wget would fail to connect and retrieve anything) or the rPi network connection (or wget could not connect at all).

    Also, some network streams from within LMS still worked when others failed, so, logically, LMS itself MUST BE capable of streaming (or those streams that worked could not have worked).

    A restart of the rPi fixed this issue. ALL streams now work.

    But why? How can only SOME streams be affected from within LMS while the URLs for those streams that failed in LMS WORK from an SSH prompt on the same LMS host? I suspect (!) it's something to do with how Perl handles network streams (since that's what LMS is written in, and though I know a little bit of Perl, I'm no Michael Herger with his knowledge of how Perl works).

    If we know why this occurs, we can determine whether it can be avoided (or whether it's simply too much work to avoid and a restart should actually be the preferred "solution").
    Last edited by gstalnaker; 2021-05-18 at 08:59.

  2. #2
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,852
    It's complicated.

    As you have not provided any details on version, nor stations - only a general answer can be given. In any case this is my opinion - there is nothing certain but some specific instances can be examined and maybe fixed.

    Network connection from LMS to station has many layers (e.g. LMS, Perl, OS, NIC, Router, ISP, CDN, Server farm, Station, security) and each one can have a cache or some sort of "memory". So a network problem can persist because the cache is returning an "old " error and not bothering doing a complete request.

    Caching has been around for a long time. On telephone networks if you call a number and it fails (e.g. engaged) and you call the number immediately afterward the exchange can be programmed, if time interval is too short, to not retry the call but return last failed tone - this is to avoid overload of network.

    In the case of network connections, resetting a system (e.g. LMS, Picore, Router) breaks the associations at various levels and so some of the caches are cleared. This is often the reason why something works if you leave it alone overnight or for a period of time.

    wget or curl just start, run and then stop - no point to caching within the application also at an OS level - the process will change for each so caching will be minimal (e.g maybe DNS) and so forth.

    LMS is unlike simple applications like VLC, wget, curl etc. in that it stays up & running often for hours, days, week non stop. it is also single threaded and has to handle many players which will be accessing many of the same sources (e.g. Tune-in, Spotify, MAI). So it has lots of measure to improve performance main one is caches. Caches have a maximum size and also expiry times. Entries can be "refreshed" and expiry times reset.

    If a connection attempt fails, then LMS will cache the result (unless told not ot cache) and return the errors until the cache expires. I think sometimes, if the user retries often, they get the cached failed response so a connection will remain "fail" for a period of time even though the initial "fail" problem may have been transient.

    In your specific case - "connection timeout" there may be other issues making things worse. In the last 12 month this error has become very closely associated with https connection problems. The best https support is on latest system. LMS http support was improved from 7.9.4 but mainly 8.0 & 8.1 IIRC even small changes up to onwards up to 8.1.2.

    LMS relies on SSL/TLS support from the OS so if the underlying OS is not up to date then for example the latest TLS level may not available to LMS and some station require it.

    Most stations use CDNs/server farms to handle network traffic and there has been cases where some CDN nodes/servers requires https whereas other did not - for the same station so depending on load balancing a https connection may or may not be required.

    There are also some cases where some stations refuse LMS request yet work OK on other players. I know of one such instance where LMS uses a UA string for HTTP requests which identifies it as "iTunes" but an old version and so the station rejects LMS requests based on the UA string. I think a recent "mixcloud" plugin issue also had similar problem.

    So without specific information on versions and problem URL - it is not possible to say whether your problem is generic or whether there are some instances which can be fixed.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •