Sometimes I observe that, after several days, the UPnP interface isn’t responding to commands. I was wondering if it was possible to reboot the system by accessing an URL or other program accessible interface, such that I could schedule a reboot every week or so.
Thanks.
Can you elaborate in what way the “UPnP interface isn’t responding to commands”? Do you mean like a request to play a track doesn’t work? Or do you mean like a request to change the Bartok’s input doesn’t work? Is the Mosaic app able to connect to your Bartok when this happens?
While the UPnP protocol is used for browsing the media server, selecting tracks to play etc., I believe control of Bartok’s settings etc. is actually via HTTP/JSON, not UPnP.
In this particular scenario, Mosaic is still working but UPnP not alive. The main evidence is that the Bartók ceases to be a render device that can be found through UPnP discovery.
Maybe next time this happens I could try to obtain some logs, but in previous circumstances, I simply did a shutdown / power on cycle and things were back to normal - thus my question about a url or command-line based reboot for the Bartók.
You could try soft-resetting the streaming network interface.
That said, in over a year of owning the Bartok, I’ve never once experienced any UPnP bugs where it stops responding. I’m guessing more likely something else is going wrong on your home network that gets “reset” when you reboot your Bartok (like a fresh IGMP Join request for example).
Did the problem only start happening lately? Is your Bartok connected to the same Ethernet switch as the UPnP Server? If you’re using a managed Ethernet switch, check if IGMP Snooping is turned-on, just disable that and see if the situation rights itself. 
Thanks. I’m aware of that screen, but I haven’t been able to access the URL for the reset function. My observations tell me that the reset button does not point to a URL, but a jquery that will manipulate the request, possibly within the context of a web session - I did not investigate it further.
If I have to visit a page to click in a button, then it is no simpler that walking to the unit and pressing the Power button right there …
That said, many thanks for your interest.
There is no way to reboot the device via the network nor is there any plan to add this functionality.
Typically this is an issue with the network and its multicast configuration. I usually see this type of instability when a managed switch with an improper configuration is used. Rebooting the device generates a new announce / subscribe cycle which forces the device to be discoverable again. Eventually the network starts blocking discovery traffic again and the device disappears.
Can you post some information on your network configuration?
Thank you for your reply. I appreciate the comeback, even if it means that the function is not available.
The Bartók and the computer trying to access it are both connected to a 5-port unmanaged switch of the simplest kind, a TP-Link unit model TL-SG105.
These two connect to the network by using one of the wired ports of an ASUS router model RT-AX88U, being configured as an access point. There’s no switch management capabilities in the configuration screens for this router. I think that it is fair to assume that it does not provide any management capabilities over the switched ethernet ports.
Is there anything else that could be interest, regarding my network configuration ?
A quick Google search unfortunately reveals that switch has IGMP Snooping ON by default and is not configurable - it’s listed in the specifications, and was also confirmed by a TP-Link Community forum post by a TP-Link Staff;
IGMP Snooping is not by itself necessarily a problem, especially when properly implemented on good managed layer 2 switch. But it wouldn’t surprise me if the TP-Link switch has problems forwarding UPnP/SSDP multicast frames after some time, and a Bartok reboot kicks the switch back into action for awhile.
Aside from trying another LAN switch, you could just plugg both your Computer and the Bartok directly onto your Asus RT-AX88U switch ports and see if the problem is resoled. But check that you Disable UPnP Media Server and IGMP Snooping functions on the Asus. 
Thanks for the pointer. I assumed “unmanaged” meant “unmanaged” but it sounds like some management capabilities are still there. I’m assuming IGMP is not being used to control a multicast that is within the same LAN, but the simple fact that the switch is doing some filtering makes it a potential problem source.
I don’t have two wires available to bypass the switch and connect both units to the router downstairs, but I will see if I can come up with an alternative test.
Thanks again.
Thats right, the Bartok uses IGMP to ensure participation in any broadcast of service availability, it doesn’t actually use multicast streams otherwise. For a typical home network, there’s little need to turn on IGMP Snooping on the local LAN switch. Occasional multicast broadcast flooding all Ethernet ports is a non-issue.
Your TP-Link Switch supports IGMP v1/v2 Snooping, but the dCS Bartok puts out IGMPv3 packets; I wonder if thats possibly giving your TP-Link Switch a headache 
Hi
Just checking on recommended network switch settings for the Bartok. Using a cisco sg300p. Should igmp v3 be enabled? Thank you very much
Hi Mike, best to just disable IGMP Snooping globally on the switch. 
Cheers, sometimes bartok loses connection to the network and sometimes mosaic loses connection- just checking recommended network config for both bartok and switch. Thank you very much.
Do note though, as Andrew posted elsewhere, there are known Mosaic issues which could be contributing to what you’re experiencing.
Cheers, we are not able to change the router due to isp restrictions. We have a decent switch. Just checking optimal settings. Tried static vs dhcp IP address without much difference. Usually mosaic works well but we still occasionally get duplicate device, dropouts, etc. Wired connection to mosaic via pc would be good but emulators for iOS don’t work too well. Any advice would be appreciated. Thank you very much.
Thanks for the link @Anupc. That makes more sense. I’ve been suspicious that IGMP snooping would really be the problem for packets not traveling outside of the LAN. The idea that the discovery code needed improvement seems more likely.
