Without having changed anything, both Hifiberries dont play any music no more when I choose them as a device in Spotify. The Spotify app on my phone says that my hifiberry is playing the music, but it isnt. And every 5 or 10 seconds it skips to another song.
Its not a hardware problem, since the Hifiberry Webradio is working fine. And I never experienced something like that before. Anybody else noticed this strange behaviour recently?
yes, my hifiberry systems started behaving very erratically yesterday with spotify and hifiberry os and stopped playing. It also seems that my HEOS Denver receiver connection has some problems with the spotify player (it starts and stops), so something is wrong with the spotify environment.
Hi, I had spotify casting not work anymore just since a few days.
In my case, It had to do with the host file. The host ap-gew4.spotify.com is set to resolve to 104.199.65.124
You can verify this by checking the file after logging in to your hifiberry via ssh.
nano /etc/hosts
Will show a line for spotify
104.199.65.124 ap-gew4.spotify.com
When you would do a DNS resolution on your pc or laptop (e.g. Powershell command below). The IP is different. So my guess is that the IP for that host changed and spotify on the hifiberry couldn't function properly...
resolve-dnsname ap-gew4.spotify.com
Name Type TTL Section IPAddress
---- ---- --- ------- ---------
ap-gew4.spotify.com A 294 Answer 34.158.1.133
FIX
Just comment out the line from the hosts file.
Edit the hosts file
nano /etc/hosts
Change the line
104.199.65.124 ap-gew4.spotify.com
into
#104.199.65.124 ap-gew4.spotify.com
and save: Ctrl+S (When prompted to save to the same location. Confirm so that the change is written to /etc/hosts)
From then on, I could cast music to spotify again.
That worked for me - I think I added the line in the past in order to handle another IP-change.
I installed today hifiberryos and Spotify didn't work. Thanks for the suggestion, it worked for me. I was beginning to fear that I bought an expensive paperweight :)
Diederik: Great; this makes Spotify work again! :-)
HiFiBerry team: could you fix this issue with an update for 32 bit HiFiBerry OS (20230404) ?
Works for me. Thanks a lot!
For fs sake, I had broadband/router change the same days and spent hours trying to find what’s the problem with the new box… Was suspecting something name resolution related, though.
Yeah,
There probably will have been a reason for it in the past to force it to resolve to that IP.
I can't guarantee this will work for the future but for now that does the trick:)
Well, their ”fix” on hardcoding it into /etc/hosts was not forever either. DNS servers maybe were temporarily (or in specific countries) out of whack back then and the trick lived on.
Worked for me, thank you!
i tried to make a PR - https://github.com/hifiberry/hifiberry-os/pull/575/commits/9c7add12f093223982f241d9e17482f977921537
Editing /etc/hosts will not work since it will reset on every reboot or anytime the spotify service crashes, you need to remove the ExecPre line setting the ip in /usr/lib/systemd/system/spotify.service and then reboot
We do ot plan any new 32bit releases.Our development efforts go into the new 64bit version. However, feel free to edit /etc/host.
And yes: There is a reason for hardcoding the IP in /etc/hosts: It was necessary to make Spotify work for some people. So even if it works better for you without this, doesn't mean, it's the best way for everyone. Spotify seems to use different connfigurations in different parts of the world.
But editing /etc/host doesn't work as I mentioned ;-) You're force feeding an IP which is wrong, if DNS is not resolving then maybe set it but doing it without even checking seems a bit brutal?
But in any case - it doesn't work at all for me, even on the 64bit dev branch
Also, interested to hear speculation on what prevents librespot and/or vollibrespot from successfully resolving these same way as native clients do?
Just remove the sethost statement from the service definition:
https://github.com/hifiberry/hifiberry-os/blob/master/buildroot/package/vollibrespot/vollibrespot.service
It's in /lib/systemd/system
I won't speculate on any internals of librespot and the Spotify protocol. We simply don't know anything about it, we're just using the available Open Source software for HiFiBerryOS.
I knew you wouldn’t, but someone else on thread might.
It would be, though, up to your system, hifiberry os, to provide a working solution at this level. Hardcoding /etc/hosts is not done or necessitated by either of those libraries and washing your hands with ”just using available OSS” is a poor excuse when you advertise Spotify-feature (As part of an OSS, but in turn used to market the hardware. I know there’s bunch of disclaimers.). It being OSS simply also provides you with the protocol and connect logic right in their github, if you _want_.
Hey @Brendan, how were you able to reproduce the hosts line to be reinserted? I have stopped/started the spotify service and I rebooted the pi but in none of the cases the line
#104.199.65.124 ap-gew4.spotify.com
reverted back to
104.199.65.124 ap-gew4.spotify.com
So just curious, because I consider updating /usr/lib/systemd/system/spotify.service to adapt the line mentioned in the PR (https://github.com/hifiberry/hifiberry-os/pull/575/commits/9c7add12f093223982f241d9e17482f977921537). But if I can't get it to be reset then I'll wonder why that is and that will keep me awake at night😅...
Diederik you need to modify /usr/lib/systemd/system/spotify.service on the target and remove that execPre line as in the commit. Note that confusingly the one you need to edit is spotify.service but it's actually vollibrespot.service in buildroot (it gets renamed). Basically just removing /etc/hosts doesn't work because when the service is started by systemd it appends the /etc/hosts file.
If anyone is feeling lazy just do this on the target:
sed -i '/ap-gew4.spotify.com/d' /usr/lib/systemd/system/spotify.service
sed -i '/ap-gew4.spotify.com/d' /etc/hosts
reboot
Hi Brendan, I think you misunderstood what I was trying to convey.
Currently I only commented the line in my /etc/hosts file, like this:
#104.199.65.124 ap-gew4.spotify.com
I have restarted the spotify service and have rebooted my hifiberry, pulled it from power etc but the /etc/hosts file stays with that line commented - so Spotify keeps working fine.
In your scenario, that line got uncommented after a reboot. So was your fix also to comment the line or to remove it from the /etc/hosts? That was what I am trying to figure out: how a reboot on my hifiberry resulted in different behaviour as yours 😁
Diederik you're right, commenting out will actually also work, just not removing the line. This is because the set-host-ip binary (/opt/hifiberry/bin/set-host-ip) does a check before editing the hosts file and isn't smart enough to check if it's commented out or not.
Apologies for the confusion, I never commented out the line, just removed it (because made no sense to leave it :)).
Ok thanks, good to know why the behaviour was different then.
But you're right, it doesn't make sense to keep that info stored as a commented line and it's better to fix it at the source.
Ah this took me way too much time, tried various router configurations, firewall settings, port forwarding, and turns out to just be a hosts setting, my god....
Please change this @HiFiBerry team or at the VERY least give a warning in the WebUI of HiFiBerryOS... Just when you navigate to 'Sources' -> Spotify Connect', add 1 line of text, this will save many people many hours of searching :)
Thx Diederik, you're a hero!
Any chance one of you guys can write a basic stept by step for less tech/code savy people?
@Benni Hal I‘m going to fix this later today, if I have time i‘ll provide a guide, ask any Chat-Bot on how to do that for now.
What is your „starting-point“? Can you access your raspberry-pi via ssh/terminal?
Yes, I can access through ssh/terminal (putty) but have never done or used that before. I'll see how gpt or something can provide me with terminal commands. Thanks, ttyl.
Thanks for not making fun of me... It's running again (thanks gpt and diederik who actually worte it down exactly...) and I hope you guys had a good laugh for my question... :-D
Hi @Benni , glad to see you got it working. Nobody wins if you'd get laughed at for asking. Kudos to you for trying, finding the information and applying it!