After a lot of investigating and cross-testing, the issues are
pinpointed as follows:
- The root couse of the issue can be:
* network issue
* restart of the squeezeserver service.
This is of course not strange. A network issue or a restart of the
service leads to a disconnect. BUT imho the pla
Some extra information:
When the player is disconnected (and as such presumable frozen), I see
this in the logfile:
Code:
[21-01-19 16:20:20.1919] Slim::Networking::Discovery::gotDiscoveryRequest
(85) gotDiscoveryRequest: deviceid = 7, revision = 4.13, MAC = 00:04:20:
Redrum wrote:
> I would still encourage taking one at a time out of the mix. For
> example, a radio rebuffered and it cause the boom to lock things up.
> Take out either the radio or boom, and see what happens. Maybe you can
> zero in one one or two problem players.
> Jim
Hi Jim,
I will spend
Redrum wrote:
> if you are using wifi with a receiver, don't discount the possibility.
> Especially with receivers. Trust me and many others on this. Just search
> "receivers" in this forum :p. Since you have allot of players synced and
> carnage (more than one player affected) happens when one
Hello all,
Thanks for all your replies.
I understand your concerns about Wi-Fi. I know it strength doesn't say
it all. But I am sure that Wi-Fi is not the issue I am facing now. As
said I once in a while have short disconnects, but most of the times,
this makes the player reconnect again, all o
Hello all,
I have a strange issue now for about some time (more than a year).
I 'm running LMS (latest beta) on Windows 10 for quite a while (used to
run Windows Home Server in the past, but upgraded to Windows 10 5 years
ago i think). I have 9 players connected: 3x receiver, 3x radio, 1x
boom,
I can confirm this issue, but I think it has nothing to do with SSL:
Code:
[20-12-30 14:16:43.9967] Slim::Networking::Repositories::__ANON__ (147)
Failed to fetch
http://downloads.sourceforge.net/project/lms-to-cast/dev/repo-sf.xml: Connect
timed out: Bad file descri
