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. ------------------------------------------------------------------------ bpa's Profile: http://forums.slimdevices.com/member.php?userid=1806 View this thread: http://forums.slimdevices.com/showthread.php?t=114600 _______________________________________________ Squeezecenter mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/squeezecenter
