No, reboot doesn't help fix it I'm afraid. It works after the restart
for nearly a day but then falls into "Too many open files" again (see
log attached) and the web UI won't open unless I restart Logitech Media
Server. Any suggestions as to how I might narrow down the problem? I
doubt that it
OK, it might be a system issue that only affects LMS :-). LMS gives the
following status info:
- Logitech Media Server Version: 7.9.0 - 1488878280 @ Wed Mar 8
14:37:44 CUT 2017
- Operating system: Windows 10 - EN - cp1252
- Platform Architecture: 8664
- Perl Version: 5.14.1 - MSWin32-x86-
Good question. I have consciously changed two things concerning my
Squeezebox system:
- Enabled the Spotify plugins, found that spotifyd.exe was faulting,
assumed this was causing the unreliability and so disabled the Spotify
plugins once more.
- In an effort to resolve the reliability i
Interesting: your logs do look similar. It's been 24 hours now and,
with www.mysqueezebox.com taken out of the VPN (so it goes via my ISP as
normal) I've not had any error messages whatsoever in my LMS log and LMS
has not become unresponsive. I think we should let it soak a little
longer though.
Well, it lasted for a few days. I restarted LMS at 20:36 on Thursday
and there were no significant errors in the log until 17:54 on Sunday,
when it said (full log attached):
Code:
[17-06-25 17:54:44.0542]
Slim::Networking::SqueezeNetwork::Players::_players_error (368)
A further update on this: I left a ping going in the background to
www.mysqueezebox.com on the same machine that LMS is running on.
Everything has been good for a few days but, just now, I noticed that
the ping was timing out. Sure enough, LMS was unresponsive. However, I
could browse to www.my
Hi Michael, thanks for responding.
Ping only failed because the IP address it was using for
www.mysqueeezebox.com stopped responding; once ping was restarted and a
DNS lookup established the new IP address ping was fine. LMS went into
its unresponsive state at around the same time and remained in
My LMS system has developed a problem recently where my Squeezebox
Radios (i.e. more than one of them are doing this) will wake-up on an
alarm to play random songs but will then stop playing after about 10
seconds and either switch to the default alarm track or fall silent.
Sometimes they will re
FYI, I did some more detailed logging of the alarm in my daughter's room
coming on this morning, see attached. The only fly in the ointment is
that I can't be completely sure that an error occurred because, being a
student, she slept through the entire thing. I've looked through the
log and ther
It's a Squeezebox Radio and yes, max bit rate is set to 128 kbits/s (on
all my players) so as not to be too ambitious on the wifi.
Rob Meades's Profile: http://forums.slimdevices.com/member.php?userid=533
View this thread:
OK, I've switched the alarm to play just the small number of tracks I
have in MP3 and removed the bit-rate limiting, we'll see what happens.
Rob Meades's Profile: http://forums.slimdevices.com/member.php?userid=533
View thi
Oh, is there a setting somewhere I may have flipped to cause LMS to
perform transcoding in this case, or is it simply doing that in order to
implement the bit-rate limiting that I set?
Rob Meades's Profile: http://forums.sl
Got it, I will just switch off bit-rate limiting then.
Rob Meades's Profile: http://forums.slimdevices.com/member.php?userid=533
View this thread: http://forums.slimdevices.com/showthread.php?t=107622
_
So, with bit rate limiting removed the problem remains. This morning
alarms came on in two rooms at 07:00 as planned; in one room ("Front
Bedroom Player") the Squeezebox Radio began playing a random song, then
went silent after ~10 seconds, then some seconds later it switched to
the default alarm
Right, I've given up on Winders and moved everything to Ubuntu and a
nice fresh installation, no lame, all vanilla stuff. Hopefully things
will (a) work and (b) remain more stable.
Rob Meades's Profile: http://forums.slimd
I have now switched to Linux (Ubuntu) and find that exactly the same
problem occurs with LMS on Ubuntu (log attached): after some time LMS
becomes unresponsive, possibly triggered by a break in connectivity. I
have seen one of the IP addresses occupied by www.mysqueezebox.com stop
responding to pi
B*gger, LMS still goes unresponsive on me when I'm running it on Ubuntu,
see 'here'
(http://forums.slimdevices.com/showthread.php?107537-Logitech-Media-Server-unresponsive-debug-help-please&p=890328&viewfull=1#post890328).
Any advice on logging settings that would help me establish what the
devil
I agree that it's not experienced frequently but I'm also not the only
person who has seen this problem, see 'ElwoodSC's comment'
(http://forums.slimdevices.com/showthread.php?107537-Logitech-Media-Server-unresponsive-debug-help-please&p=886557&viewfull=1#post886557).
This is a completely fresh LM
I'm on LMS 7.9.0 - 1488878280 @ Wed Mar 8 14:09:34 UTC 2017.
I'll take lsof's at regular intervals.
> I believe the sometimes troublesome UPnP/DLNA plugin is enabled by
> default though. It's not generally a problem, but in some networks it
> triggered some corner case.
Understood, it is now di
Find attached two files containing the "lsof" output for PIDs 8337
(squeezeboxserver_safe) and 8339 (squeezeboxserver), taken 36 hours
apart. The first one looks normal but the second one is starting to
look odd: squeezeboxserver has 348 file handles open to
"SqueezeboxRadio". FYI, I have 5 Sque
Excellent stuff: the player that has 348 out of the 358 open socket file
handles is the one that is in fringe coverage. Would you expect
intermittent network connectivity to a SqueezeboxRadio to cause this
kind of issue? I'll perform a factory reset on it anyway.
--
Nothing clever, just that player is at the bottom of the garden and so
clings onto coverage.
I'll run Wireshark filtered on that player's IP address and see what
crops up.
Rob Meades's Profile: http://forums.slimdevices.co
The build up of open file handles still seems to be occurring after a
factory reset of this SqueezeboxRadio so I've taken a Wireshark capture.
It's too big to upload here so it's available at 'this link'
(https://1drv.ms/f/s!AqUHa_qo4gdB7XGdzBtZHs4GpX_U) if you can draw any
useful conclusions from
Apologies for delay in replaying and many, many thanks for the detailed
analysis. lsof to match log attached in case it's still useful.
I can't think of anything obvious that happened on Tuesday evening. We
would have been sitting down to dinner at that time, no power failures
that would have p
24 matches
Mail list logo
