Open matt1432 opened 4 days ago
thlucas1
commented
4 days ago It looks like it’s having an issue retrieving Spotify Connect device information for the device at IP address 192.168.0.11.
Can you reboot that Spotify Connect device, and try setup again?
Also, what is the manufacturer device type for that device?
Note that Chromecast devices are not supported by the integration.
matt1432
commented
4 days ago The device it's trying to connect to is not even at that address though. There's nothing at 192.168.0.11.
The Spotify Connect device I'm trying to use is spotifyd on the same machine as home-assistant.
thlucas1
commented
4 days ago I am not too familiar with spotifyd, but it appears to be registering itself with zeroconf as a Spotify Connect device. SpotifyPlus simply does a zeroconf service browse on your local network to determine what devices have registered themselves as Spotify Connect devices. It then tries to connect to each one to call the Spotify Zeroconf getInfo service.
That is what's failing - the zeroconf service browse indicates that a Spotify Connect device is registered at the 192.168.0.11 IP address, and is failing to connect to it because there is nothing at that address.
We are going to have to do some zeroconf troubleshooting to resolve this. Have a look at my Spotify Connect Zeroconf Troubleshooting page for more details, starting with the DNS-SD Service Browse topic. It walks you thru the process that is used by the SpotifyPlus integration to discover Spotify Connect devices on your local network.
After googling spotifyd, it appears that you may need to start it as a system service. Can you confirm that the spotifyd service is running?
UPDATE - Another note, can you access the spotifyd device from the Spotify Mobile App? or Spotify Web App? If not, then you may want to start there as spotifyd should be recognized by those clients as well.
matt1432
commented
4 days ago I can access the spotifyd device from other devices and it is running as a service.
I couldn't find how to use dns-sd on my linux machine but I used this instead:
$ avahi-browse --resolve _spotify-connect._tcp.
+ enp0s31f6 IPv4 homie connect _spotify-connect._tcp local
= enp0s31f6 IPv4 homie connect _spotify-connect._tcp local
hostname = [homie.local]
address = [100.64.0.10]
port = [33798]
txt = ["CPath=/" "VERSION=1.0"]This is accurate. I don't understand why the integration is trying a different IP
thlucas1
commented
4 days ago What do you get if you call the Spotify Connect Zeroconf getinfo endpoint directly? Issue the following from a desktop browser:
http://100.64.0.10.:33798/?action=getInfo&VERSION=1.0http://homie.local.:33798/?action=getInfo&VERSION=1.0
Note that you may need to change the 33798 port number to something else if you have restarted the spotifyd service since your previous reply. Just issue the avahi-browse --resolve _spotify-connect._tcp. command again to get the current port number.I don't understand why the integration is trying a different IP either. It tries the address value first, then the hostname alias if that fails. The question is why does it see the 192.168.0.11 address / FFB8F0023FF4CC80C9174596.local. hostname values? That FFB8F0023FF4CC80C9174596 looks like a Spotify Device ID, and will probably match what is returned in the getInfo call.
Is there some sort of network translation going on somewhere? Or maybe a proxy server setting in spotifyd configuration that's causing it?
matt1432
commented
4 days ago http://100.64.0.10.:33798/?action=getInfo&VERSION=1.0 returns this:
{"accountReq":"PREMIUM","activeUser":"","brandDisplayName":"librespot","deviceID":"7c30b5f0ee82d548b1b4d21941e71e104966b77c","deviceType":"Speaker","groupStatus":"NONE","libraryVersion":"0.4.2","modelDisplayName":"librespot","publicKey":"kuHJdz7hFYoHRQRS5xWh2nxvmRhXUe6ZJlczFdXn6zj7vgZc5a4EjiYZWA04vAKYWb9VLQlwaV6FHfkuwh3ByAgTHgRejF5flsDD+DM9GNe0Q/DyB2TkRBwTsKl/3ZI2","remoteName":"homie connect","resolverVersion":"0","spotifyError":0,"status":101,"statusString":"ERROR-OK","version":"2.7.1","voiceSupport":"NO"}http://homie.local.:33798/?action=getInfo&VERSION=1.0 doesn't resolve
Instead of 192.168.0.11, it's now trying 192.168.0.92, which is the IP of my Atom Echo voice assistant.
This is the output of avahi-browse --resolve _spotify-connect._tcp. now:
+ enp0s31f6 IPv4 FFB8F0023FF4CC80C9174596 _spotify-connect._tcp local
+ enp0s31f6 IPv4 homie connect _spotify-connect._tcp local
= enp0s31f6 IPv4 FFB8F0023FF4CC80C9174596 _spotify-connect._tcp local
hostname = [FFB8F0023FF4CC80C9174596.local]
address = [192.168.0.92]
port = [5356]
txt = ["Stack=SP" "VERSION=1.0" "CPath=/zc"]
= enp0s31f6 IPv4 homie connect _spotify-connect._tcp local
hostname = [homie.local]
address = [100.64.0.10]
port = [33798]
txt = ["CPath=/" "VERSION=1.0"]The only device visible from the Spotify apps is homie connect
matt1432
commented
4 days ago Is there some sort of network translation going on somewhere? Or maybe a proxy server setting in spotifyd configuration that's causing it?
I am connected to my tailscale / headscale network, but all the devices involved are on this same network, which is the 100.64.0.X IPs
thlucas1
commented
4 days ago Not sure how it's finding a 192.168.0.92 address if you are on a 100.64.0.X subnet.
It looks like the CPath is different (e.g./zc) on the 192.168.0.92 device. I wonder if it's a Spotify Mobile app client maybe? Or maybe Spotify on another smart device in your home (TV, AVR, etc)?
What output do you get for the following link:
http://192.168.0.92:5356/zc?action=getInfo&VERSION=1.0
matt1432
commented
3 days ago I get nothing at the link. However it has disappeared from avahi-browse --resolve _spotify-connect._tcp.
But I was wondering, is that error also causing the Failed setup, will retry: Platform spotifyplus.media_player not found message? Or is that another issue?
thlucas1
commented
3 days ago That should not cause the failed setup. The reason I was asking about it was that it was on a different subnet, and I do not understand how that could happen. The 100.64.0.x IP subnet is obviously not the same as the 192.168.0.x subnet; the 192.168.x.x range is considered to be "local", and I am still not sure how the 100.64.0.x fits into all of this. Spotify Connect will only recognize devices registered to the local network.
I do know that the Zeroconf data is coming back with the 192.168.0.11 address, and SpotifyPlus cannot access that address.
As the log messages indicate, it then tries to use the hotsname (DNS alias) value of FFB8F0023FF4CC80C9174596.local. and fails there as well.
Do you know what the IP address of your Home Assistant image is? Here's an example of what I see for mine (e.g. 192.168.1.248):
You can also do a ping command against the url used to access Home Assistant (e.g. homeassistant.local):
ping homeassistant.local
Is it on the same 192.168.0.x subnet?
matt1432
commented
3 days ago I have home-assistant on bare-metal, this is the result of ip a:
enp0s31f6: 192.168.0.87/24
tailscale0: 100.64.0.10/32
Technically these are both local networks which is why it's looking in both I guess.
Do you have any ideas for what caused the failed setup?
thlucas1
commented
3 days ago I must say I am still at a loss for what is causing this. You would think it would be able to resolve the address, since the SpotifyPlus integration is running on the same machine that the spotifyd server is running on.
I am looking through the spotifyd configuration configuration wiki, and it talks about a zeroconf_port setting:
# The port at which `spotifyd` is going to offer its service over the network (TCP).
# If not set, a random port > 1024 is used. For the service to be discoverable on the
# local network via mDNS, both the mDNS port (5353 UDP) and the random or fixed
# zeroconf port need to be allowed through any active firewall.
zeroconf_port = 1234What do you have the zeroconf_port value set to in your spotifyd config?
And have you allowed activity on that port through your firewall?
The bottom line is that something is blocking the connection between the SpotifyPlus integration and the spotifyd service. If we can figure out where that is happening, then we can fix it.
matt1432
commented
3 days ago I have zeroconf_port set to 33798 and it is open
thlucas1
commented
3 days ago Researching TailScale ... when you are configuring the SpotifyPlus integration, are you accessing the Home Assistant devices page using the tailscale url? or are you accessing it using the 192.168.x.x address? In my case, I access the SpotifyPlus intgeration page using http://homeassistant:8123/config/integrations/integration/spotifyplus. I also have external secured access setup using DuckDNS, but I never use the external address while configuring devices / options.
If you are using the tailscale url, can you try accessing HA using the 192.168.x.x address, and then configure the SpotifyPlus integration.
Just throwing out ideas here, as I am not familiar with TailScale or how it works; from the reading I have done, it appears to secure access to HA and in the process of that utilizes a different url for accessing HA.
System Health details
System Information
Dashboards
dashboards | 3 -- | -- resources | 0 error | /var/lib/hass/ui-lovelace.yaml not found views | 0 mode | yamlRecorder
oldest_recorder_run | September 16, 2024 at 3:05 AM -- | -- current_recorder_run | September 23, 2024 at 4:12 PM estimated_db_size | 34.89 MiB database_engine | sqlite database_version | 3.46.0Spotify
api_endpoint_reachable | ok -- | --SpotifyPlus
integration_version | 1.0.57 -- | -- clients_configured | 1: matt (premium) api_endpoint_reachable | okChecklist
Describe the issue
After setting up everything, I get the following error in the UI:
Failed setup, will retry: Platform spotifyplus.media_player not foundI am trying to set this integration up with spotifyd on the same machine
Reproduction steps
Initializingis doneDebug logs
Diagnostics dump
No response