Good Afternoon,
After struggling with this for some time now, I have narrowed and sorted the problem I have been experiencing with Volumio.
For a few weeks now (probably way more, I gave up a few times), my Volumio install just stopped working entirely for spotify songs.
When ever I used
cat /var/log/volumio.logit would return very generic “Error: This socket has been ended by the other party” messages yada yada yada…
Anyways, after pulling my hair for a very long time, installing, reinstalling, installing older version, installing newest version… all came back with the same messages and spotify playback was a no go. I decided to take a look at the traffic logs on our firewall (this volumio machine is being setup in my office at my workplace, which is behind Palo Alto firewalls) and noticed that there was a significant amount of DNS traffic being denied to the Volumio machine.
Turns out, Google DNS is hard coded into:
/etc/resolv.conf.headwhich on boot, injects 8.8.8.8 and 8.8.4.4 to the top of the nameserver list in:
/etc/resolv.confUnfortunately I have no control over this firewall, like a lot of other people wouldn’t be able to adjust any ISP hard block on 8.8.8.8 (more common than you would think). Now I figured that even with google DNS in there and secondary DNS being our local DNS servers, this would still failover nicely, however it seems once it can’t get through to google dns, it just hangs? Even the web interface begins improperly updating values like the volume slider or time scale on the audio playback. (i.e. you would have to switch between browse and playback before the audio volume slider updated to the new value).
Either way. This was broken for months, I fixed it by removing Google DNS. It seems weird to have hard coded DNS values in any default networking config, as you cannot guarantee everybody access to google DNS, but you can guarantee they have access to their ISP’s DNS… and if that is not working, there is a bigger issue at hand than simply a change of DNS servers.
Not really a bug in the true sense… more of a potential wider issue. Could even just be a matter of a KB article or something on a wiki that explains how to change the DNS values if issues persist.
Feel free to do with this information what you will.
Cheers,
Kyle.
Edit: I guess that means the real issue at hand is improper DNS failover to secondary servers.