Issues when settings LMS -*addr command line args.
Opened this issue · 36 comments
Hej Philippe,
there are no issues when I do not change the below mentioned command line args. Everything work perfect (paring, hearing, etc.)
BUT when setting the lms command line args:
--advertiseaddr <IP-Server> \
--cliaddr <IP-Server> \
--httpaddr <IP-Server> \
--playeraddr <IP-Server> \
--streamaddr <IP-Server>
The connection between LMS, the AppleTV and the Bridge just stop. The AppleTV is not shown anymore as a player in my LMS players list.
All I found so far is that there is a connection missing in netstat.
WITHOUT cmd line args:
root@[/export/lmsdata/cache/InstalledPlugins/Plugins/RaopBridge] netstat -anp | grep sque
tcp 0 0 <IP-Server>:36647 0.0.0.0:* LISTEN 79952/squeeze2raop-
tcp 0 0 <IP-Server>:60168 <IP-Server>:3483 ESTABLISHED 79952/squeeze2raop-
udp 0 0 0.0.0.0:5353 0.0.0.0:* 79952/squeeze2raop-
udp 0 0 0.0.0.0:5353 0.0.0.0:* 79952/squeeze2raop-
root@[/export/lmsdata/cache/InstalledPlugins/Plugins/RaopBridge] netstat -anp | grep perl
tcp 0 0 0.0.0.0:3483 0.0.0.0:* LISTEN 79916/perl
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN 79916/perl
tcp 0 0 0.0.0.0:9090 0.0.0.0:* LISTEN 79916/perl
tcp 0 <IP-Server>:39949 0.0.0.0:* LISTEN 79916/perl
tcp 0 0 <IP-Server>:3483 <IP-Player>:58316 ESTABLISHED 79916/perl
tcp 0 0 <IP-Server>:3483 <IP-Server>:60168 ESTABLISHED 79916/perl
udp 0 0 0.0.0.0:3483 0.0.0.0:* 79916/perl
udp 0 0 <IP-Server>:57159 0.0.0.0:* 79916/perl
udp 0 0 0.0.0.0:33326 0.0.0.0:* 79916/perl
unix 3 [ ] STREAM CONNECTED 675261 79916/perl
WITH these command line args I get hardly the same output with just one line missing:
root@soundcity[/export/lmsdata/cache/InstalledPlugins/Plugins/RaopBridge] netstat -anp | grep sque
tcp 0 0 <IP-Server>:52591 0.0.0.0:* LISTEN 78997/squeeze2raop-
udp 0 0 0.0.0.0:53735 0.0.0.0:* 78997/squeeze2raop-
udp 0 0 0.0.0.0:5353 0.0.0.0:* 78997/squeeze2raop-
udp 0 0 0.0.0.0:5353 0.0.0.0:* 78997/squeeze2raop-
root@soundcity[/export/lmsdata/cache/InstalledPlugins/Plugins/RaopBridge] netstat -anp | grep perl
tcp 0 0 <IP-Server>:9090 0.0.0.0:* LISTEN 78951/perl
tcp 0 0 <IP-Server>:9000 0.0.0.0:* LISTEN 78951/perl
tcp 0 0 <IP-Server>:40491 0.0.0.0:* LISTEN 78951/perl
tcp 0 0 <IP-Server>:3483 0.0.0.0:* LISTEN 78951/perl
tcp 0 0 <IP-Server>:3483 <IP-Server>:58310 ESTABLISHED 78951/perl
udp 0 0 <IP-Server>:3483 0.0.0.0:* 78951/perl
udp 0 0 <IP-Server>:53037 0.0.0.0:* 78951/perl
unix 3 [ ] STREAM CONNECTED 672268 78951/perl
To my understanding there is a connection missing linking the squeeze2raop bridge as a player to lms...
This behavior occurs under all the above mentioned cmd line args, leaving these out everything works again.
So far it looks to me as if there is an issue inside the squeeze2raop bridge binary, as I found no errors so far in the logs.
Could help me in finding out what's wrong here?
Thank you very much in advance.
Rouven
Did you try to make it bind to LMS's IP in the options?
I did try that right before just to be shure.
That did not help.
in the lms-prefs I have:
---
_ts_autorun: 1634482878
_ts_autosave: 1634482878
_ts_bin: 1662402928
_ts_configfile: 1634482878
_ts_debugs: 1634482878
_ts_eraselog: 1634482878
_ts_logging: 1634482878
_ts_opts: 1634482878
_ts_profilesURL: 1662402928
_ts_useLMSsocket: 1662402897
_version: 0
autorun: 1
autosave: 1
bin: ~
configfile: raopbridge.xml
debugs: ''
eraselog: 0
logging: 0
opts: ''
profilesURL: ~
useLMSsocket: 1
and in raopbridge.xml I have:
<?xml version="1.0"?>
<squeeze2raop>
<common>
<streambuf_size>2097152</streambuf_size>
<output_size>1764000</output_size>
<enabled>1</enabled>
<codecs>aac,ogg,ops,ogf,flc,alc,wav,aif,pcm,mp3</codecs>
<sample_rate>96000</sample_rate>
<resolution></resolution>
<resample>1</resample>
<resample_options></resample_options>
<player_volume>-1</player_volume>
<volume_mapping>-30:1, -15:50, 0:100</volume_mapping>
<volume_feedback>1</volume_feedback>
<volume_mode>2</volume_mode>
<mute_on_pause>1</mute_on_pause>
<send_metadata>1</send_metadata>
<send_coverart>1</send_coverart>
<auto_play>0</auto_play>
<idle_timeout>30</idle_timeout>
<remove_timeout>0</remove_timeout>
<alac_encode>0</alac_encode>
<volume_trigger>0</volume_trigger>
<prevent_playback>stop</prevent_playback>
<persistent>0</persistent>
<encryption>0</encryption>
<read_ahead>1000</read_ahead>
<server>?</server>
</common>
<interface>SERVER-IP</interface>
<slimproto_log>info</slimproto_log>
<stream_log>warn</stream_log>
<output_log>info</output_log>
<decode_log>warn</decode_log>
<main_log>info</main_log>
<slimmain_log>info</slimmain_log>
<raop_log>info</raop_log>
<util_log>info</util_log>
<log_limit>-1</log_limit>
<migration>3</migration>
<ports></ports>
<device>
<enabled>1</enabled>
<credentials>b4c2b3cee6b2ff809dd9c4ac9f6dd1e53167484bf0b4fa253b7d131dd70c3796@192.168.47.202:7000</credentials>
<friendly_name>AppleTV</friendly_name>
<mac>tt:ff:1e:d5:s3:58</mac>
<name>AppleTV</name>
<udn>somestuff@AppleTV._raop._tcp.local</udn>
</device>
Can you give me the raopbridge.log?
BTW in <interface> the "SERVER-IP" is you replacing the address by that litteral, right ?
yes, the "SERVER-IP" is like "192.168.111.12".
here are the files. both made with "all items below" to get most out of it....
raopbridge_failing.log
raopbridge_working.log
their names should be self explanatory.
On the failing one, which address do you bind LMS to? 192.168.111.12 vs 192.168.47.12 otherwise?
As you pointed out on ShairTunes2W, I'm using serverAddr() to find the LMS' address before issuing the command line. Strange that it remains 47.12
it's aleays 192.168.47.12. always.
sorry for trying to anonymize it.
if i confused you: apologies!
comparing both log files it looks as if the server discovery "discover_server" is not working correctly
No worries - I don't think you're giving a lot information by mentioning that private IP, but you can change it later of course. So if this is always 192.168.2.47, then I'm very confused 😄 because it's the same code in both cases then. I've never checked LMS, but it seems to NOT answer discovery request when you specify its binding address. Sounds unlikely ...
okay... slow ;o)
i hope i did not introduce a 192.168.12.47...
both scenarios have the lms server interface ip 192.168.47.12. in the cmdargs scenarios this is THE ip address. the raop bridge runs on the same host. here i did not specify an ip manually. if there is one defined that might be my paraniod anonymization ;o)
so, far it also seems to me as if it is not answering the discovery with a "manually given" ip.
btw: if the confusion I created is too much, I can also create a new set of logs etc. But anyway it is always 192.168.47.12. promise ;o)
Since the issue is interesting to me, I had a look into your code.
There is a line that puzzles me a bit:
https://github.com/philippe44/LMS-to-Raop/blob/0c0c78fb54faa160d9c8a13d44599cd80d5529af/application/squeezetiny/slimproto.c#L776
In that line an below a socket is opened for doing discovery broadcasts. I would assume that a broadcast IP is something like 255.255.255.255 or 192.168.47.255. At least it should not be an ip address like "192.168.47.12". The latter would be the case when the if-statement concludes to line L777...
I found the "original" part in ralphy's code for squeezelite. He does not use such an if-statement. He simply sets the boradcast address. See: https://github.com/ralph-irving/squeezelite/blob/bc72c0de3fff771540a2a45aaafafed539387b3c/slimproto.c#L788
So probably the if-statement set the wrong broadcast addresss and the broadcast never succeeds...
Does that make sense and help?
I would have tried that on my own, but so far I have not yet compiled everything.
Non it's on purpose, AFAIR. If there is no registered server, I broadcast a UDP discovery packet on ANYADDR, otherwise I send the same packet to the set server which is supposed to answer, unless something has changed in LMS when the IP address is forced. I can't remember exactly why, but I think there was a reason why I did that instead of just bypassing discovery.
[edit] it came back to me why I did that: regular squeezelite just sends a HELO message to LMS when it's address is set but I need a few server parameters that are only sent as a response to a discovery UDP packet. So I always send one, either a broadcast or to the set server.
Okay. Thanks for remembering.
In any case these lines seems a little odd to me as the socket is set to SO_BROADCAST and then uses a unicast address to send the broadcast out...
Maybe it is a specialty that I run all components on one machine at the same ip. Maybe that block, confuses stop or ... the discover process...
May I ask you for your opinion:
As far as I am, the issue should reside in the bridge rather than in LMS as all other components running on the same machine and IP including ShairTunes are working as expected. Squeezelite on another raspi is also working correctly and connecting to the server when I force LMS to a specific IP. The "area" where the issues occurs should be around the discover_server routine in slimproto then. Maybe it's the broadcast or maybe it's the poll???
Do you remember which info you needed from LMS using the broadcast. Maybe that is not needed anymore as LMS was re-written afterwards to sent the necessary things...?
Do you remember which info you needed from LMS using the broadcast. Maybe that is not needed anymore as LMS was re-written afterwards to sent the necessary things...?
I still need these, like CLI port and version number. The SO_BROADCAST option is not needed it's true when I sent to the specific server, but AFAIK, it does not create a problem.
Any chance you could take some wireshark traces so we can see what's happening? What I do not understand in your logs is that the command line for squeeze2raop is exactly the same in both cases, so the only change is on LMS side. I'm not saying that the issue is not with me, but trying to figure out, I need to sort out the differences and this is where it is.
I tried to compile the bridge here. It off topic, but: How do I get that compiler error solved when it comes to raop-play:
519/source/include ../raop_play/src/rtsp_client.c -c -o bin/aarch64/rtsp_client.o
../raop_play/src/rtsp_client.c:27:10: fatal error: ../include/external_calls.h: No such file or directory
27 | #include "../include/external_calls.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
How do I get external_calls.h, where do I find that?
I suspect something is happening where LMS only listens to the address it is bound to (I just checked the LMS server code) and somewhere with your system, sending to broadcast (from the bridge) does not loopback to the socket LMS is listening to (not anymore ANYADDR). It might be about the way your distro is configured. Can you try to set the LMS server address of the bridge (not the binding interface) - it's options below, in "common" sections.
Any chance you could take some wireshark traces so we can see what's happening? What I do not understand in your logs is that the command line for squeeze2raop is exactly the same in both cases, so the only change is on LMS side. I'm not saying that the issue is not with me, but trying to figure out, I need to sort out the differences and this is where it is.
Of course we can arrange some wireshark logs! I can also re-package, some logs to make things clear (no anonymization, promoise!) Concerning the wireshark, it would help me if you could provide what you need and probably how to get it. On my mac there is a wrieshark on the LMS-raspi not. But I think I can help.
Only think, I will be off home until sunday from today on.
Any chance you could take some wireshark traces so we can see what's happening? What I do not understand in your logs is that the command line for squeeze2raop is exactly the same in both cases, so the only change is on LMS side. I'm not saying that the issue is not with me, but trying to figure out, I need to sort out the differences and this is where it is.
Of course we can arrange some wireshark logs! I can also re-package, some logs to make things clear (no anonymization, promoise!) Concerning the wireshark, it would help me if you could provide what you need and probably how to get it. On my mac there is a wrieshark on the LMS-raspi not. But I think I can help.
Only think, I will be off home until sunday from today on.
I would try setting the server first, it might solve the issue
I suspect something is happening where LMS only listens to the address it is bound to (I just checked the LMS server code) and somewhere with your system, sending to broadcast (from the bridge) does not loopback to the socket LMS is listening to (not anymore ANYADDR). It might be about the way your distro is configured. Can you try to set the LMS server address of the bridge (not the binding interface) - it's options below, in "common" sections.
I am really puzzled about that. I find it kind of "interesting".
For your information: My distro is Raspberry Pi OS 64-bit (lite-image). Updated to the latest.
I would try setting the server first, it might solve the issue
Just tell me if you need help, that it the least I can do!
BTW: Thank you very very much for your help!
In the plugin settings, "common parameters", set LMS address to your IP address. If this still does not work, try the loopback
In the plugin settings, "common parameters", set LMS address to your IP address. If this still does not work, try the loopback
Hej, I am back from vacation and already checked your hints.
Using
<common>
...
<server>192.168.47.12</server>
...
</common>
Looks promising. Using "127.0.0.1" does not help at all.
I am observing thing now a little bit to see if it is stable.
Is there a way to make the pluging set the server address automatically to that fixed value based on the cli args? Then I would try that. To me it makes perfect sense to set it to a "value" when the cli args are set, as the plugin should usually reside on the server machine....
Deleted the last comment and put content/explanation into added issue #29
Hi philippe,
after my hassle with pairing for a plain new plugin installation I just checked again what helps...
Well, setting der server ip via common parameters to 192.168.47.12 makes the apparatus play music. But for some reason other LMS players dissapear from my players list. there is just the AppeTV/RaopBridge being listed anymore.
Send me the new config file
Here they are (service file for the proper cmd-args & raopbridge.xml)
lmsd@.service.txt
raopbridge.xml.txt
@philippe44 Hej, may I kindly ask, whether you were able to check the config and have some hints for me?
@philippe44 I read a bit through the code and saw, why probably the broadcast discovery is done: The server version is needed - in pcm.c (https://github.com/philippe44/LMS-to-Raop/blob/0c0c78fb54faa160d9c8a13d44599cd80d5529af/application/squeezetiny/pcm.c#L107) to do kind of a - call it - "workaround".
In squeezelite's pcm.c there is no such server version check done (anymore?) (https://github.com/ralph-irving/squeezelite/blob/bc72c0de3fff771540a2a45aaafafed539387b3c/pcm.c#L79).
So here now the question:
Is squeezelite's pcm.c worth adapting to squeeze2raop or are there any other specialities needed? Maybe there is also another way of getting the version or it can be left out due to the squeezelite code.
in any case I do not feel quite well in judging about that so maybe you can give some input.
So far I would then check whether the discovery and connect routines in squeezelite solve my issue.
The next thing then is adapting pcm.c which seems harder due to all the "bytes" stuff...
Sorry but I'm in a middle of a full reconfiguration of my build system and it's very complicated, I don't have much time available these days. So as of today, your situation is that when the bridge connects, all other players disappear? Including regular SB?
@philippe44 No problem for me. I saw that you are reconfiguring and as I know my skills I do not want to think about what you are dealing with. So I totally understand that you do not have that much time.
Yes, when I set the bridge's IP in common parameters, I get all others disappear.
To not bother you with work: I looked into the squeezelite code and compared it a bit to the bridge's code.
I think I will give the way squeezelite discovers and sets the server ip a try.
The thing I think that is strange: in case of a set server ip, the bridge uses a socket configured for broadcasting to send over a unicast ip. probably this make things crash.
Why do I think that: my squeezelite instances cope very well with setting LMS ip addreses via command line. it's only the bridge that has issues...
I would keep you up with the results, if that's okay.
What would be interesting is to see LMS log because obviously something is happening there. I do feel it's more on this side when it receives a UDP discover while being bound to a specific address. Logs might tell (try the ones regarding slimproto)
@philippe44 You were right (of course): It seems not to be an issue with the bridge. BUT: There is no error message in the log files! I tried "slimproto" and "protocol".
Using lmsd without cmd_args for an ip address I get for each player a discovery and an accept. With cmd_args for an ip address I get just on discovered player and one accept. No other... So I end up with the bridge...
Can we close this item?
Well, the issue still remains, but I also have no clue how to get it solved. So far it is not that urgent anymore on my side...