Perform the following steps:
- switch on Arcam SA30 from “cold” not standby, version 1.62, build 1027 is used
- start Arcam Music Life iOS app, build 3301 and attempt to select SA30 in audio output, should be listed as UPnP Renderer
- Alternatively look from iPad for SA30 available to Airplay
- Alternatively use browser to connect to web interface
Actual result
In the case of 2, SA30 is not listed for a good ten minutes or so
In case of 3, similarly device is not displayed for same sort of period
In case of 4, browser times out and reports page not available, later refresh works.
Expected result
Connectivity via any method should be available immediately following SA30 start-up
Additional information
Watching my router I see the SA30 allocated an IP address very quickly, so it is connected to my network, but it still takes a good while to show as available for any streaming or casting. Connection method is wifi and strong signal available, amp is within 3 meters of the router. Wifi is available at 2.4 and 5ghz and settings synchronised so only appears as one network.
This sounds to me like your router could be blocking multicast broadcast messages.
We use a protocol called SSDP in order to discover devices. We first connect to a multicast group (239.255.255.250, port 50000) and send out a search request for available devices. Devices are given a 5 second window to respond (they actually respond much quicker than this), and then discovered devices pop up in the list of available outputs.
If broadcast is blocked, we may not be able to receive responses to the search request. According to the UPnP specification, in addition to responding to search requests, devices have to announce their presence regularly (between 10-30 minutes), so I think that’s why its showing up later.
The fact that the SA30 doesn’t show up in AirPlay (or presumably Cast either), makes me think there’s something else at fault here.
You have a few options available, but Customer Support would be able to help you out. Try each of the following steps, and see if the situation is improved.
- Reset Net Settings and see if that helps MENU > System Settings > Net Reset.
- Look for any settings on your router related to UPnP, Multicast, or Broadcast, and ensure they’re enabled.
- Temporarily connect an Ethernet cable between the SA30 and your router.
- Split the wifi into separate 2.4 and 5g networks and get your iPad and SA30 on the same one
Thanks paul
I’ve actually already been through the firewall settings in my router and selected “allow any” in terms of protocols and ports for the IP address of the amp….against my better judgement also on inbound rules as well as outbound rules. This doesn’t seem to have made any difference at all, which really had me scratching my head. wouldn’t SSDP usually be port 1900 UDP on that multicast address? I’ll try a firewall rule specifically for that and see, although from what you describe this would suggest the initial advertisement by the amp isn’t working and then the amp is doing that again maybe 10 minutes later? That doesn’t explain the web client not being available though right?
Interestingly UPnP is enabled on my router by default (I’m with Sky) and the only thing I ever see pop up in the UPnP port map table is my Xbox console. Maybe I’m not patient enough to observe what’s going on 
However the advertisement period is set to 30 minutes and advertisement period TTL (in hops) only set to 4. It’s possible one or the other of those could be upsetting things I suppose? Here is the help info on this from my router…I think I probably need to consider changing these…what do you think?..
Advertisement Period
The Advertisement Period is how often the Sky Hub will advertise (broadcast) its UPnP information. This value can range from 1 to 1440 minutes. The default period is for 30 minutes. Shorter durations will ensure that control points have current device status at the expense of additional network traffic. Longer durations may compromise the freshness of the device status but can significantly reduce network traffic.
Advertisement Time To Live
The time to live for the advertisement is measured in hops (steps) for each UPnP packet sent. A hop is the number of steps allowed to propagate for each UPnP advertisement before it disappears. The number of hops can range from 1 to 255. The default value for the advertisement time to live is four hops, which should be fine for most home networks. If you notice that some devices aren’t being updated or reached correctly, then it may be necessary to increase this value.
Ps. Loathe to separate the 2.4 and 5 ghz unless I absolute have too, not sure what that would do to the Sky mesh (with multi-room boxes elsewhere in the house). I think this will be bottom of my list of things to try tbh!
So just tried upping the UPnP advertisement TTL hops to 8 to start with. And I removed any firewall rules so clean slate,
Amp showed up as attached to network in about 44 seconds and actually amp start was much faster unless this is some kind of weird placebo effect! Then opening musiclife the amp was there straight away showing as output. Web client ready to go too.
I hope it’s that simple. Will have to keep an eye on things, but I’ve never seen everything connect so quickly tbh. Airplay available too.
Perhaps this was causing some timeout and retry in the startup sequence that was delaying everything else?
Thinking about it I also posted about trouble with Qobuz playback and that seems to get into trouble at about 30 mins. Coincidence given my UPnP advertisement period?
Further to this, whilst I haven’t rebooted anything I’ve listened to three albums straight via Qobuz without issue. Until the Xbox console in the house was switched on. I then got issues with playback stopping as reported in the firmware thread. The Xbox console is also a UPnP renderer. I am wondering whether it’s possible there is some clash between it and the amp. I subsequently switched off the Xbox and rebooted the amp, but it had bother restarting the streaming still. In fact after reboot and Xbox off, the amp said it was starting to play, no sound came out and then it swapped the track name on the display for “no signal”, before returning to the airable root menu. Proper confused now…
Yes it would. Forgive me, port 50000 is our control port, and I had just been working on control, hence the typo!
You shouldn’t have to specify any firewall ports, as these are typically for external use. Our traffic doesn’t leave the network so that shouldn’t be an issue. From that information, it does sound like increasing the TTL value is of interest, and it sounds like it’s helped you out. I’ll pass that info onto or Customer Support folks, as this could be a good first step in diagnosing issues.
This is understandable, and shouldn’t really matter. Leave it for now.
It shouldn’t matter. To give you a little context, the network module in the SA30 is much smarter than previous UPnP based modules. Whether you tap on a device in MusicLife under UPnP or Cast, it doesn’t matter we use a different API. The advantage of this API is we can send a list of playback URLs to the module and then let the module handle the logic. This also has the advantage that you can switch your phone off if you wish and playback will continue. After the initial device discovery, we don’t use UPnP or SSDP.
As for your Xbox, again, that shouldn’t really affect it, but it may. I’ll ask around and see if anyone here is on Sky broadband.
Thanks……it’s all a bit odd. I guess I need to do some more testing before I deciding to rollback firmware.
Yes I get your point about the firewall rules, I kind of answered my own question as I went to look at them and immediately thought yeah that’s WAN not LAN ….school boy error, it’s not like I work in IT or anything 
The thing that I can’t get my head around is why qobuz seems to have the issue but tidal does not…
My home network is based around a TruNAS server, which is a bit ‘homebrew’, but I did find that I had to gor around the routers and servers and
1 - reenable SMB1 / NetBIOS functions (which in a sane world would be deprecated and turned off for security reasons)
2 - ensure UPnP was ON
3 - double check nothing had added itself to the “blocked devices lists”
4 - double check that UDP was not in the “blocked services” lists
5 - disable “Netgear Armour” (and reset it)
6 - enable RIP on Both directions
7 - double check that the IP range for DHCP was granting a valid address to the device on the right subnet by checking on “attached devices” and DHCP, then assign a fixed IP to the Arcam Unit against its MAC address
(that last step allowed me to provide direct paths to the server as well, which was just “fluff” rather than helpful, I expect)
Some of that was overkill, but once done, it has been flawless since
1 Like