Volumio Snoozio

Volumio Information

Volumio Version: 2.882
Hardware: Raspberry Pi 4B
DAC: IFI Zen USB DAC

I’ve been really enjoying Volumio, mainly using the Qobuz integration, for the past couple of months, but there is one thing that’s bugging me and I wonder if others have seen it or know of a fix…

Basically if I leave the system alone for a few days, then fire up my iPad and try to connect to volumio.local it takes … ages … really slow loading of every page component, initially it’ll be saying my account is not connected, before finally refreshing and showing virtuoso.

I’ve used both Safari and Chrome on the iPad and seem to get the same. I suspected DNS settings may have been slowing things down so I forced it to use CloudFlare 1.1.1.1 and 1.0.0.1 and thought things may have got a little better, but not at all sure now.

The weird thing is, as I write this on my iMac, I’ve just gone to volumio.local and it appeared instantly, so I picked up the iPad… and again, painfully slow and showing MyVolumio as ‘Not Connected’ before eventually refreshing (approx. 1-2 mins) and showing ‘virtuoso’. It’s like there’s a compatibility problem between the iPad browser and the web server on the Volumio distro causing timeouts and slowness, which I’d love to investigate further but don’t really know where to look.

Has anyone seen similar or any suggestions where to look / how to diagnose?

Yes - there are a bunch of threads on these boards about all the bugs. It used to not be like this and was flawless until the last several releases. I am hopeful that they are working on it. I have especially noticed the slowness with Qobuz. As an alternative you can use mConnect and use your Volumio hardware as an endpoint, and that works flawlessly. No delays whatsoever on the Pi4.

Oh I’ve read a fair few bugs here too :slight_smile: haven’t seen anything on this one though. It does seem weird that it’s only affecting the iPad and not the Mac.

My initial thought was that there’s a power-saving feature in the volumio image and it’s making the RPi go to sleep. Then first access, it was taking time to get up and running again. It was only as I typed the message that I gave it a quick go with the Mac and iPad side-by-side and saw it wasn’t a sleep issue.

I’d really rather use the Volumio interface if at all possible.

Is it a ‘modern’ iPad? I use an old iPad 2 as a display and that is mighty slow if I try to use the UI.

Yep, it’s a 10.5" iPad Pro, so no more than about 3 years old, plenty quick enough. It just smells of network timeouts or something like that. I’d suspect the wireless only the iMac is also on the WiFi so there’s no difference in terms of networking.

1 Like

Hi, You might try to save the shortcut to Volumio.local on your iPad springboard, so you are able to shut down the browser immediately when Volumio is unresponsive. This happens to me on a daily basis, but restarting a session with the shortcut always does the trick. Btw, it is very helpful to create shortcuts this way for each Volumio setup you use in your network. I have four, and firing up one specific setup has never been easier.

1 Like

Good tip Martinvb, but yes, one I already use daily :slight_smile: I have an icon for Volumio in my taskbar on the iPad that does exactly this. Killing it off and restarting it does certainly help some of the time.

It’s interesting that the same problem can be seen on Chrome on the iPad as well - another red herring that led me to believe it was an RPi sleeping problem. On iOS I believe Chrome is using WebKit the same as Safari so it’s no great surprise that I can see similar problems.

Would be great to be able to sniff out exactly what is waiting on what… the fact that you’re seeing it as well is… reassuring :smiley:

Not 100% sure about this particular situation but I’ve had some luck in the past for connection timeouts by turning off the ‘Private Address’ setting on the ipad for my home network. You can find the setting by going to Settings–>Wifi–>hitting the circle i icon next to your connected network and turning off ‘Private Address’ if it’s on.

Thanks for the tip. Just gave it a go and rejoined the WiFi but no difference, still really slow loading on the iPad. Strange one indeed. I’m noticing that it’s also quick to load on my iphone, so it’s just the iPad that seems to have the issue. Puzzling…

I think I may have found it…

If I use http://volumio.local it’s really slow
If I use http://192.168.0.128 it’s much quicker…

So it does appear to be some kind of DNS related issue. I’m using volumio.local on the iMac as well, so unsure why the iPad should be any different.

1 Like

I know I’m replying to myself here, but just to confirm - this DEFINITELY is the issue for me - direct IP addresses are good, volumio.local is bad, and this appears to be the case only on the iPad. I’ve been using Volumio all weekend and the difference is night and day.

Looking into this, I see all .local addresses use Bonjour / multicast-DNS as opposed to the DNS servers. I know the iPad has no difficulty seeing bonjour / Airprint printers on my network so it must be enabled and functioning. Not sure if anything anywhere else can be configured, but for now, I’m just going to avoid using ‘volumio.local’.

So anyone else suffering slow loading, give the IP address a quick go and see if it makes any difference for you too, I’d be interested to hear.

I have found that using Apple’s Bonjour protocol (which is baked into their devices) can be problematical in it’s implementation, especially on Android devices. It is not too bad in Linux, and Windows has improved greatly recently, but I wonder what happens when you go across these architecture boundaries and meet in the middle … little inconsistencies can lead to big problems. In consequence, I rarely use the .local addresses.