Sufi-Al-Hussaini writes


I would like to be able to detect when a mpd client goes out of the network while streaming, and have upmpdcli call onstop.

I tried running mpd with --stdout --verbose and it still didn’t report any errors in this situation. Although on next run, it gives:

# /usr/bin/mpd --stdout --no-daemon --verbose
config_file: loading file /etc/mpd.conf
curl: curl failed: Failed to connect to port 32576: No route to host

Is there a facility in upmpdcli to detect this?


medoc92 writes

I’m not sure that I understand what you mean. Do you mean a media server ? This should make mpd go into stop state, but upmpdcli has no further information on the cause.

Sufi-Al-Hussaini writes

Forgive me for not being familiar with DLNA terminology. By mpd client, I meant a media streaming server mobile application (BubbleUPnP/ArkMC).

I want to know if it is possible for upmpdcli to know if a mobile application leaves the network while it was streaming (serving) a media file to mpd.

If not, do you have any ideas as to how such a mechanism can be implemented?

Use case: I’m running upmpdcli on an embedded box; using the onxx hooks to power on/off my amplifier. I would like to power-off my amplifier in such cases.

medoc92 writes

No problem, I was really just not sure what you meant. When a mobile app like bubble "streams" to a dlna renderer, it is actually behaving in a hybrid way: a Control Point (remote), and a partial Media Server. Unfortunately, and especially because it’s not a full media server (for which we might be able to use UPnP discovery functions), I see no way to do what you want. The Control Point itself is not discoverable (it’s here to discover other stuff), so we can’t ping it through UPnP.

The only possible approach would be to detect and process errors (the read timeout on the server, the broken event subscriptions for the CP if any were set), but in practise there are no software functions to process this information. Probably the best bet would be an independant application, which would monitor the renderer and regularly ping any server it is streaming from. You could then decide to turn the amp off if the active server appears to disappear from the network. But this is really just a wild idea, I’m not sure how well this would work in practise. Or just turn off the amp if the renderer has been quiet for some predefined time ?

Sufi-Al-Hussaini writes

Thank you very much for taking the time to write this explanation.

Just one last question regarding: > Or just turn off the amp if the renderer has been quiet for some predefined time ?

How can I determine, in software, if the renderer is quite?

joerg-krause writes

@Sufi-Al-Hussaini I’m using a GPIO to turn on/off an amplifier. However, I am not using the onstart/onstop scripts anymore to handle the GPIO, but an ALSA hook. This way, the amplifier is turned off, if playback is paused.

Sufi-Al-Hussaini writes

Thanks @joerg-krause, I didn’t know about ALSA hooks. I’ll read about them.

medoc92 writes

> How can I determine, in software, if the renderer is quiet ?

I guess that you could monitor if the playing time is progressing. Actually the problem is all the boilerplate that you need to get to the point where you can do this. There is a sample c++ program for libupnp which could be a basis for this, but I have no definite idea how this would work, this will be trial and error.