No connection in LMS: Looping with "slimproto_run:579 error reading from socket: closed" on android

[iMartyn]

squeezelite compiles under termux with one modification to the Makefile.pulse (adding -DNO_FAAD to OPTS) and pulseaudio appears to work.

However when running ./squeezelite-pulse -n phone -s 192.168.1.62 -d all=debug where 192.168.1.62 is my lms server, I get the attached debug output.

The player never appears in LMS, and clearly appears to be attempting to reconnect over and over.

Running on another machine on my network works fine, at least with a release binary, so either something is broken in master or this may be specific to android.

Either way, on a non-google-services android phone there's not a lot of options to play music from your LMS any more (SqueezePlayer has switched to paid, SBPlayer was never not-paid), so it'd be nice to say "hey, just use termux and squeezelite".

Debug log: debug.log

[Edited to add clarification that this is actually a non-working state]

[ralph-irving]

It appears that squeezelite cannot access the network. From the debug.log the mac address is all zeros and the termux wifi says;

Why does htop or netstat not work on my device

In order to stop leaking sensitive information via side channels, Android has blocked access to certain interfaces in /proc. This is done for your privacy.

Specifically:

/proc/net/*
/proc/loadavg
/proc/stat
/proc/uptime
/proc/version
/proc/vmstat
And few others.

Restrictions vary between Android OS versions. Thus Android 7 is less restrictive than 8/9/10+. You can use root to bypass them.

Unfortunately, I don't have an android device that works with termux

[iMartyn]

well that put me on the right track for when the phone is on the lan, -m with the correct mac address (oddly enough ip a shows it fine).

That means yay, audio on my phone when I'm in the house, which... yeah, not really when I want the phone to be able to play. When I want it to play is when I'm VPN'd in. Now, VPN doesn't have a MAC address, and somehow SqueezePlayer managed it.

Does this mean that squeezeplayer is actually using ethernet not IP? Is there an encapsulation that perhaps the other player was doing over IP that lms supports? so many questions...

[tmancill]

@iMartyn I ran into a similar issue connecting to an LMS instance on a local LAN that was addressed by specifying the IP and port on the LMS server. That is -s 192.168.1.62:9000

[ralph-irving]

Squeezelite uses udp broadcasts to discover lms, which many vpn solutions don't enable/support by default. So using -s and the ip address is needed. However, you don't need to include the port number.

Also, from your log, squeezelite can't load the FLAC library.

[12:30:57.105511] load_flac:289 dlerror: dlopen failed: library "libFLAC.so.8" not found

It's likely that the library has different case than the default. You can change the name of the library that SL tries to load in the LINUX section of squeezelite.h

[iMartyn]

Well here's VERY interesting : I always specify the IP as my LMS runs in kubernetes and therefore doesn't respond to UDP broadcast traffic, just exposes ports via a service, and it is now in a working state except....

• On the local network, works perfectly fine contacting 192.168.1.62
• VPN'd in, other things including SSH work perfectly fine, but not squeezelite
• SSH-tunnel opened on localhost for 9000 and 3483 with squeezelite connected to 127.0.0.1 works fine also

I am stumped as to why the ssh tunneling works but vpn (tun0) doesn't.

Also, a suggestion, given that the way you're detecting mac addresses gets 00:00:00:00:00:00 perhaps squeezelite could detect that and crash with an error saying "couldn't detect mac address, please pass -m <>`?

[hilsonp]

This thread helped me while I was trying to connect a Squeezelite x64 from a Windows 10 host to my LMS server running in a docker container on my local network.

My error was use the -s xxx.xxx.xxx.xxx:9000

Once I removed the port 9000 all went fine.

I think an indication in the help page saying that the default port is 3483 would put people on the right track as they would not use the 9000 port as I thought I should.

Thank you very much for your work.