Strange connection issues between Radio and LMS

[reinholdk]

I've got two Radios on WiFi that both have occasional connection issues with LMS on a Win10 PC.
Don't know when it started, maybe some time after updating LMS to 7.9.0?

The symptoms are:
- the local music I've selected to play is playing for maybe 10 or 15 mins and then stops
- the now playing screen shows the artist/album/artwork from the previous playlist
- the now playing screen doesn't indicate that anything is playing (no progress, no play symbol)

There are two workarounds that fix this behavior:
- rebooting the Radio, or
- switching to MYSB and then back to LMS from the Radio's menu

It doesn't seem to be a WiFi/network issue.
If the problem occurs, then:
- from the Radio's Settings/Advanced/Diagnosis/ServerInformation screen both MYSB and LMS connections are shown as OK for all ports
- from the LMS WebUI the correct playlist for the player is shown and it shows progress
- WiFi signal is more than 60%

Unfortunately I couldn't find any pattern for the occurances.
For some days all works fine and then for some days the problem appears.

I typically find this problem in the morning after switching the Radio on, but it seems to occur also during the day, even with radio stations (according to family members).

Maybe it occurs when the server PC is woken up from energy saving mode?
During the night WiFi is switched off and the LMS server PC is sleeping in energy saving mode and the Radio is in standby (displaying the clock). But in the morning when I turn the Radio on, WiFi is already on and the LMS PC is usually up and running (woken up by the Windows scheduler; in cases when the PC is sleeping, the Radio wakes it up promptly). I do it this way since years.
BTW, LMS runs as a Windows service and the music is stored on a local drive.

Here's the server log. Maybe the "errorNeedsClient" message is relevant here?

[17-05-11 21:35:27.5707] main::init (388) Starting Logitech Media Server (v7.9.0, 1488878280, Wed Mar  8 14:37:44 CUT 2017) perl 5.014001 - MSWin32-x86-multi-thread
[17-05-11 21:35:30.1959] Slim::Utils::SQLiteHelper::postConnect (374) Optimizing DB because of missing or empty sqlite_stat1 table
[17-05-11 21:35:30.2754] Slim::Schema::forceCommit (2149) Warning: Trying to commit transactions before DB is initialized!
[17-05-11 21:35:31.4304] Slim::Utils::SQLiteHelper::postConnect (374) Optimizing DB because of missing or empty sqlite_stat1 table
[17-05-11 21:35:31.5016] Slim::Schema::forceCommit (2149) Warning: Trying to commit transactions before DB is initialized!
[17-05-11 21:35:32.0084] main::checkDataSource (1111) Warning: Schema updated or no media found in the database, initiating scan.
[17-05-11 21:49:17.0420] main::init (388) Starting Logitech Media Server (v7.9.0, 1488878280, Wed Mar  8 14:37:44 CUT 2017) perl 5.014001 - MSWin32-x86-multi-thread
[17-05-12 05:44:37.7391] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:xx:xx:xx, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-12 06:00:40.7148] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:yy:yy:yy, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-13 08:17:05.2652] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:yy:yy:yy, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-13 08:17:05.5287] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:xx:xx:xx, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-14 09:25:25.9819] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:yy:yy:yy, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-14 09:25:26.8255] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:xx:xx:xx, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-15 06:40:35.5276] Slim::Utils::Misc::msg (1244) Warning: [06:40:35.5255] Error: Unable to read at least 16 bytes from file (only read 13).
[17-05-16 05:44:35.8359] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:yy:yy:yy, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-18 02:35:58.3184] Slim::Web::JSONRPC::requestMethod (443) 00:04:20:xx:xx:xx: request not dispatchable!
[17-05-18 02:35:58.3235] Slim::Web::JSONRPC::requestMethod (443) 00:04:20:xx:xx:xx: request not dispatchable!
[17-05-18 02:36:04.3356] Slim::Web::JSONRPC::requestMethod (443) 00:04:20:xx:xx:xx: request not dispatchable!
[17-05-18 02:36:04.3398] Slim::Web::JSONRPC::requestMethod (443) 00:04:20:xx:xx:xx: request not dispatchable!
[17-05-18 02:36:10.3479] Slim::Web::JSONRPC::requestMethod (443) 00:04:20:xx:xx:xx: request not dispatchable!
[17-05-18 02:36:10.3521] Slim::Web::JSONRPC::requestMethod (443) 00:04:20:xx:xx:xx: request not dispatchable!
[17-05-19 05:44:36.0257] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:xx:xx:xx, status, -, 10, menu:menu, useContextMenu:1, subscribe:600
[17-05-20 08:32:08.7240] Slim::Web::Cometd::handler (422) errorNeedsClient: 00:04:20:xx:xx:xx, status, -, 10, menu:menu, useContextMenu:1, subscribe:600

I also checked the /var/log/messages file on the Radio and it shows network errors but I can't tell yet whether they are relevant or normal when LMS server is sleeping.

I also increased debug log levels for several categories but couldn't separate the wheat from the chaff.
Any advise here?

[JJZolx]

Since the first Squeezebox I owned, some 12 or more years ago, I've seen the issue where the server thinks it's streaming music, but the player produces no sound. It used to be fairly common, but I've seen it much less frequently in recent years.

I doubt anything that has changed in LMS with regard to streaming, but I'm seeing a lot more playback stoppages on my Radio lately. I have no idea what might be causing it, but the wireless signals are good. I sometimes keep the Radio in my kitchen a few feet from the microwave, and using the microwave oten causes a song to stop, then LMS then skips to the next one. But lately it's just been stopping for no apparent reason and doesn't begin playing again on its own until I hit the play button.

The Radio, I'm convinced, was never fully baked. Logitech abandoned the product line and disbanded the development team before the firmware was debugged to the same level of reliability of prior products. It's the least mature of all the SB products, but alas, nobody is likely to ever touch the firmware again. It is what it is.

[reinholdk]

I didn't have this problem in the past years. It only started earlier this year, probably after I switched from LMS 7.7.x (or 7.8?) to 7.9.0 (I don't say it's caused by 7.9.0).
I just installed 7.9.1. Will see if it happens again...

[bpa]

Are you using static IP or have arrange for DHCP to always assigned same IP to Radio

If Radio is losing connection and DHCP reassign IP address - you can get problem like this.
"errorneedclient" usually means the client (e.g. GUI on Web, Radio, App or old SB player display) that initiated a request is no longer connected to LMS.
Any other messages in log file ? the 10-15 min connction failed will have a reason - just that it may require enabling logging for a module to show the reason.
Try enable slimproto logging to see if losing connection creates an entry in log.

[reinholdk]

It has happened again - with LMS 7.9.1.

Still don't think it's a WiFi issue.
DHCP server is configured to always provide the same pinned ip addresses for the SB devices and LMS server PC (in fact, for all devices that are regularly in the network).
And it usually (always?) happens for both Radios. And switching the Radio to MYSB and back to LMS clears the issue. So the network seems to be ok.

Now I have enabled debug logging for slimproto. Will report back when it happened again. Thanks so far.

[iPhone]

It has happened again - with LMS 7.9.1.

Still don't think it's a WiFi issue.

.
.
Sound exactly like a WiFi issue to me. The proof would be to put both SB Radios on Ethernet and se how they act over several days.

Quick question, do you on a 200 acre estate or are other homes near by? What I am asking is have you looked at your routers channel interference monitor? Is your WiFi Router using the default channel?

Remember unlike a simple WiFi connection with a PC surfing the Internet, more is going on and more is involved with the SB Radio over and with the WiFi connection, LMS, and the Server. I would be willing to bet that Time-outs are even involved due to Server Processes.

[reinholdk]

Thanks for the hints. I know that there are many factors influencing WiFi connectivity.

Wiring these two Radios temporarily would mean to run cables of ~10 meters over the floor. I'd rather want to avoid this. And I don't like to invest in powerlan adapters, since this setup worked over years - yes, I know, the neighborhood could have changed. And to answer your questions: yes I've checked interferences with neighborhood signals and it's still ok-ish and my access points use fixed control channels for 2.4ghz.

But what makes me think that it's not a typical WiFi issue are the following points when the problem occurs:
- I've checked WiFi signal strength on the Radio and on LMS WebUI and it was at least 60%
- I can switch the Radio to MYSB and back to LMS without problems (which obviously involves network operations) and then the issue is gone
- the music plays 10-15 minutes without re-buffering before it stops
- after I've selected and started the local music, the now playing screen shows correct track and cover information only for a second or two and then it shows no progress indication and track and cover information from before switching it to standby mode
- LMS WebUI shows correct track and progress is in sync with the music playing on the Radio

[iPhone]

Thanks for the hints. I know that there are many factors influencing WiFi connectivity.

Wiring these two Radios temporarily would mean to run cables of ~10 meters over the floor. I'd rather want to avoid this. And I don't like to invest in powerlan adapters, since this setup worked over years - yes, I know, the neighborhood could have changed. And to answer your questions: yes I've checked interferences with neighborhood signals and it's still ok-ish and my access points use fixed control channels for 2.4ghz.

But what makes me think that it's not a typical WiFi issue are the following points when the problem occurs:
- I've checked WiFi signal strength on the Radio and on LMS WebUI and it was at least 60%
- I can switch the Radio to MYSB and back to LMS without problems (which obviously involves network operations) and then the issue is gone
- the music plays 10-15 minutes without re-buffering before it stops
- after I've selected and started the local music, the now playing screen shows correct track and cover information only for a second or two and then it shows no progress indication and track and cover information from before switching it to standby mode
- LMS WebUI shows correct track and progress is in sync with the music playing on the Radio

.
.
Humor me, does your SB Radio have a battery or is there an open AC socket near your router (I am assuming the answer is yes)? So MOVE your SB Radio to the router and use as short of an Ethernet cable as you like, no need to run a 40 foot Ethernet cable when the SB Radio can easily come to the Router.

I have seen tons of these issues and solved tons of them, if you don't split the problem in half, you could very easily end up chasing your tail without ever solving your issue. By proving it happens or doesn't happen while using Ethernet also is the first and fastest way to eliminate an actual WiFi issue, splitting the problem in half.

[reinholdk]

Ok, I'll do. You've convinced me, because I'd give the same advices to somebody else having these issues.
Just waiting till the problem occurs again to see if there's some hint in the slimproto debug messages.

[bpa]

- the music plays 10-15 minutes without re-buffering before it stops

After the audio breakdown after 10-15 minutes - the log in the radio should also be check to see of Radio logs any unusual event.

As a way to check if the problem is Wifi related or LMS comms related.

Assuming LMS is not setup top proxy or transcode if you play a http MP3 or AAC stream on the Radio - the stream will play directly from station to Radio - LMS will not be involved in the communication and stream will use a single TCP connection. Does this stream play for say 20 minutes ? If yes then Wifi or IP address are not the issue -as Radiuo should keep playing a direct stream even if LMS communciation is broken.