Thank you for your donation!


Solved: Network config for Spotify Connect
#1
Hi,

Noob mode again.
I try to get Spotify Connect to work, I may need some help for network config.

My computer and my rasp are plug direct in my LAN router in DHCP mode. My phone on the wifi can get my PC on Spotify, but no Moode Spotify.
I tried to put the Moode config in Static to fix IP and DNS, but it's still change nothing. I tried also with a static ip on Wifi but nothing.

It seems pretty simple, so I think "network issue" as most of the thread about spotify connect issues...

Thanks Smile


Attached Files Thumbnail(s)
   
Reply
#2
DHCP or static IP shouldn't matter, so long as they're on the same network and subnet it should work. DHCP is usually better as you can reserve that IP on your router to avoid address conflicts.
Have you enabled Moode's Spotify renderer in the audio configuration?

Edit: Second look at the screenshot I notice that you've set a static IP for the Pi on the 192.168.0.0 subnet but the gateway is 192.168.1.1, a different subnet? Any reason why or is that a mistake? That would indeed cause a problem.
Reply
#3
Yes, it was a mistake. My router is in 192.168.0.1. Everything in 0.XX
Spotify activate. Premium account check.

My computer (LAN) can share music with my phone (Wifi), no problem. But Moode Spotify never shows up. DHCP or Static.
I tried Static because I learnt a lot of thread where DNS auto was wrong.
Reply
#4
You could try:
Code:
pgrep librespot
 On SSH, if it return nothing, it means librespot is not running for some reasons.
Reply
#5
@gillestantot

Let's begin at the beginning instead of the middle.

When posting a support request, always first reboot the moOde player and then capture the output from the System Info menu item in the moOde WebUI (or using the "moodeutl -s" command from the moOde command line [1]), and include it in the post.

In your case it tells us several useful things, including your Internet settings, but more importantly, including the startup (or not) of the Spotify Connect service. Here's an example where I've excerpted the crucial lines from the MOODE STARTUP LOG section of the command output (including the last line before and first line after the relevant Spotify lines):

Code:
1) a moOde player with the Spotify Renderer setting "On":

20200905 131121 worker: Airplay renderer (started)
20200905 131121 worker: Spotify renderer (available)
20200905 131121 worker: (librespot --name "Moode3A Spotify" --bitrate 160 --initial-volume 0 --cache /var/local/www/spotify_cache --disable-audio-cache --backend alsa --device "plughw:2" --onevent /var/local/www/commandw/spotevent.sh > /dev/null 2>&1 &)
20200905 131121 worker: Spotify renderer (started)
20200905 131121 worker: Squeezelite renderer (available)


2) a moOde player with the Spotify Renderer setting "Off":

20200906 091207 worker: Airplay renderer (started)
20200906 091207 worker: Spotify renderer (available)
20200906 091207 worker: Squeezelite renderer (available)


If the service never started then it can never be found. As vinnn suggested, a way to determine if the service is still running later is to execute the command "pgrep librespot" to get the ID(s) of the processes involved. For the same cases as above, I get:

Code:
1) Spotify Renderer setting "On" and service running:

pi@moode:~ $ pgrep librespot
329
1195
2365
27786
pi@moode:~ $

2) Spotify Renderer setting "On" or "Off" and service not running:

pi@moode:~ $ pgrep librespot
pi@moode:~ $


If the service is running, then Spotify Connect should "just work". It depends on DNS Service Discovery which is a zero-configuration networking technique. In our use case, the only requirement is that the Spotify Connect receiver (moOde) and the Spotify app (phone/tablet/PC) be on the same LAN segment AND that any intervening network devices pass the discovery protocol packets.

Here's one test of the latter using the avahi-browse command available on my Linux boxes (including my moOde players). I ran it on my Linux laptop named T520 which is connected to my LAN router/AP via WiFi on interface "wlp3s0" (which might have been "wlan0" in the old naming scheme):

Code:
xxxx@T520:~$ avahi-browse -r _spotify-connect._tcp
+ wlp3s0 IPv6 Moode64 Spotify                               _spotify-connect._tcp local
+ wlp3s0 IPv6 Moode3A Spotify                               _spotify-connect._tcp local
+ wlp3s0 IPv4 Moode3A Spotify                               _spotify-connect._tcp local
+ wlp3s0 IPv4 Moode64 Spotify                               _spotify-connect._tcp local
+ wlp3s0 IPv4 c01b1ae2e423a69a-0                            _spotify-connect._tcp local
= wlp3s0 IPv6 Moode64 Spotify                               _spotify-connect._tcp local
   hostname = [moode64.local]
   address = [fe80::xxxx:xxxx:xxxx:xxxx]
   port = [39399]
   txt = ["CPath=/" "VERSION=1.0"]
= wlp3s0 IPv6 Moode3A Spotify                               _spotify-connect._tcp local
   hostname = [moode3a.local]
   address = [fe80::xxxx:xxxx:xxxx:xxxx]
   port = [34583]
   txt = ["CPath=/" "VERSION=1.0"]
= wlp3s0 IPv4 Moode3A Spotify                               _spotify-connect._tcp local
   hostname = [moode3a.local]
   address = [192.168.1.195]
   port = [37481]
   txt = ["CPath=/" "VERSION=1.0"]
= wlp3s0 IPv4 Moode64 Spotify                               _spotify-connect._tcp local
   hostname = [moode64.local]
   address = [192.168.1.201]
   port = [39399]
   txt = ["CPath=/" "VERSION=1.0"]
= wlp3s0 IPv4 c01b1ae2e423a69a-0                            _spotify-connect._tcp local
   hostname = [c01b1ae2e423a69a-0.local]
   address = [192.168.1.162]
   port = [44899]
   txt = ["Stack=SP" "VERSION=1.0" "CPath=/zc/0"]
^C
//note: it may take a few seconds for all services to be discovered so I let the program
//      run until I killed it manually instead of using the -t option to let the program
//      decide when to quit
//note: this output includes IPv6 addresses. They are benign link-local addresses in my case
//      but it's still bad practice to publish IPv6 addresses. Always xxxx out everything
//      after the first octets out of an abundance of caution.

This output indicates my laptop can "see" the Spotify Connect service on two moode players as well as a commercial device (a Facebook Portal). They were first discovered as their service names such as "Moode3A Spotify" and then reverse protocols were used to associate each service with a fully qualified hostname, an IP address, and port. 

Regards,
Kent

[1] Note that it is not necessary to use ssh to log into the moOde player command line. You should be able to run the moodeutl command remotely from any computer which has a fully functional ssh command available thusly;


Code:
xxxx@T520:~$ ssh pi@moode3a "moodeutl -s"
pi@moode3a's password:
Generating info...

S Y S T E M   P A R A M E T E R S

moOde release        = 6.7.1 2020-07-22
...
Reply
#6
Thumbs Up 
(09-06-2020, 02:59 PM)TheOldPresbyope Wrote: @gillestantot

Thanks Kent for your answer. I don't know why but this evening it works...
I restarted my router this morning for a internet connection issue, maybe he was the problem and it was probably blocking the "discovery protocol packets".

I learnt tips because of you. Thanks again.

pi@moode:~ $ pgrep librespot
1056

20200906 111321 worker: Output device (Local)
20200906 111321 worker: Spotify receiver started
20200906 111321 worker: UPnP renderer started
Reply


Forum Jump: