philippe44
Issues when settings LMS -*addr command line args.
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
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
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 :smile: 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.
Here they are (service file for the proper cmd-args & raopbridge.xml) [email protected] 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...