Hi,
when I'm streaming to the Devialet using AIR (either internet or WIFI) I see activity on all the ports on my router which have physically attached devices even if they're not involved in the music replay process. This activity stops when the Devialet is turned off.
I just wondered why this should happen. It's almost as if the Devialet is constantly polling all the other attached devices on my network. Does it do this? Anyone know why?
There certainly seems to be significant unnecessary (?) traffic on the network when Devialet AIR is running.
Thanks,
Philip
Hi Phil - Yes i have this too - streaming or just idle (via wired Ethernet). This happens in sleep mode now too as the new firmware keeps the network card active to allow power on from the app. Interestingly i just thought this was on my audio network (NAS, Mac and Switch), but i've just had a look and noticed another devices port (a data logger) on another part of my network is showing activity when the Devialet is on.
James
Hi James,
Just tried S/PDIF streaming and get even more intense activity and you're correct the activity continues when the Devialet's in sleep mode for all devices attached to my network. This seems strange. I think I will ask Thierry what's going on. Don't want to waste precious bandwidth...
Regards,
Philip
I had a partial response from Thierry - "The Ethernet card remains on even when the Devialet is in Stand By to be able to react to the ON / OFF function of the iPhone app or Android. If you want the module to not react to the remote app, you can deactivate this function in the configurator."
I tried this (General Settings>Remote>App Remote Control 'Disabled' and there is now no router activity when the Devialet is sleeping.
He didn't explain why the devices on all the router ports are being polled when the Devialet is awake. Certainly none of my other devices that can be controlled remotely e.g. Naim NDX n-Stream generate this type of network activity.
(17-Jun-2014, 16:07)PhilP Wrote: [ -> ]I had a partial response from Thierry - "The Ethernet card remains on even when the Devialet is in Stand By to be able to react to the ON / OFF function of the iPhone app or Android. If you want the module to not react to the remote app, you can deactivate this function in the configurator."
I tried this (General Settings>Remote>App Remote Control 'Disabled' and there is now no router activity when the Devialet is sleeping.
He didn't explain why the devices on all the router ports are being polled when the Devialet is awake. Certainly none of my other devices that can be controlled remotely e.g. Naim NDX n-Stream generate this type of network activity.
Presumably it checks all devices on the network as near to continuously as would be needed for it to seem instant should one of them be your phone saying "switch on" ???
[/quote]
Presumably it checks all devices on the network as near to continuously as would be needed for it to seem instant should one of them be your phone saying "switch on" ???
[/quote]
Yes, I think that must be the reason though I would have thought there might be a better way of doing it?
Interestingly when you disable the App through the configurator it is partially disabled when the Devialet is actually running. i.e. the App won't control the volume any more but it does show the volume that has been set by the remote. So it is still connecting to the Devialet and the device polling continues as before. I think this behaviour a little strange and possibly a bug
Surely it would be better if 'disable App' completely disabled it... Or you could have two parameters - one to disable it completely and one to disable wake-up
Thanks Phil - thinking back it did do this on the old firmware. I just notice it now if i'm sat in the study as i can see the lights on the switch blinking away even when it's not playing music. The change to always on for the network card fixed a bug (for me) that when first woken, the network card wouldn't always connect to the network requiring another few button presses to go back to standby and back on and then the Air app wouldn't detect the amp on the network. Devialet recognised it as a bug and fixed it.
James
I didn't notice it before but I checked (using a network packet sniffer) and indeed the Devialet broadcasts 5 UDP packets per second to 255.255.255.255 so this means every and all devices on your LAN will receive these packets. The packets are 387 bytes each, are sent from source port 45454 to destination port 45454.
The Devialet is not polling other devices but it is updating it's own status/making it's own presence known to other devices. Only the devices that have the AIR software or app installed will actually process these packets. It is indeed a very inefficient way to do it like this. It would have been more efficient to use some standard service discovery protocol like uPnP or Apple's Bonjour uses.
Try starting the air application as see what happens
no need to start streaming music... There is a lot of packet beteween the amp and client. The broadcast packets from the devialet is nothing compare to this. But it is only small packets. I guess that instead of using mulicast they are using broadcast to let clients know it's whereabouts.
(17-Jun-2014, 20:19)Antoine Wrote: [ -> ]I didn't notice it before but I checked (using a network packet sniffer) and indeed the Devialet broadcasts 5 UDP packets per second to 255.255.255.255 so this means every and all devices on your LAN will receive these packets. The packets are 387 bytes each, are sent from source port 45454 to destination port 45454.
The Devialet is not polling other devices but it is updating it's own status/making it's own presence known to other devices. Only the devices that have the AIR software or app installed will actually process these packets. It is indeed a very inefficient way to do it like this. It would have been more efficient to use some standard service discovery protocol like uPnP or Apple's Bonjour uses.
Antoine, thanks that's an interesting analysis. I'm in e-mail contact with Thierry and have mentioned it to him. Obviously their s/w team know what they've implemented but I have suggested that they could find a more elegant solution and also clean-up the 'disable App' function.
Regards, Philip