Issue 110

scctl -x <friendly name > does not necessarily stops the Receiver mode if the Sender device has the same name as the Renderer device, e.g. "UpMpd". This happens in my case when Songcast Sender and Receiver are running on the same hardware device.

This is not really an issue with scctl, but with libupnpp as the device discovery using a friendly name only returns one device. If this device is the Sender instead of the Renderer (which is bearing the Receiver service) scctl -x.

I know, that using the UDN is the safer approach. However, I wondered if the device discovery using a friendly name should find all devices having the same name. So, more like an issue about libupnpp, but as scctl is part of upmpdcli I decided to post the issue here.

Feel free to close the issue by saying: "Please use UDN instead of friendly name when using scctl".

Even if I added an easy interface to return all the devices with the same name , what are you going to do next ? You still don’t know which to stop !

So either the user makes the effort to have unique friendly names (which is useful, really: you want to know where the renderer is located !), and they can use the friendly names, or they don’t and only the UDNs can be used.

It would be trivial to write a method to return all the devices with the same friendly name, using the current discovery interface: so much so that I’m not sure that it belongs in the library itself.

It’s not really about having different renderers using the same friendly name in a network, but about having the renderer and the sender service running on the same hardware. In my case, I used the hostname when starting upmpdcli and mpd2sc as the friendly name, e.g:


In this case scctl -x UpMpd only works if the renderer device was found before the sender device. Therefore, I changed the friendly name for the sender device:


I noticed that you take care about that issue by appending "UxSender" to the friendly name in the scmakempdsender script. I did not in my custom script.

Yes, the sender is a different UPnP device, so it makes sense that it should have a different name. This is different from the situation where the Sender and other services are under the same Device.