On 2017/09/14 12:58, Plastic Sturgeon <mpd-...@plasticsturgeon.de> wrote:
> I assume it's unreasonable to spam the server with IDLE/NOIDLE
> commands many times a second.

True.  The whole point of "idle" was to keep clients from querying MPD

> But I cannot use mpd_run_idle to wait for changes, either, unless
> there is a way to interrupt the wait if a user interacts with my UI.
> What is considered the most MPD-like way of handling such a scenario?

mpd_send_idle(), then register libmpdclient's socket (see
mpd_connection_get_fd()) in your I/O event loop.

As soon as MPD sends the result, your event loop triggers your
callback, and you can use mpd_recv_idle() to read the result.  After
you're done handling those idle events, re-enter idle.

If you want to interact with MPD in the meantime, call
mpd_run_noidle() and handle idle events which may have occurred; then
send the desired commands to MPD.  Finally re-enter idle.

This is not magic.  And it's not specific to MPD.  This is basic
event-based programming.  Just one connection and one thread, no
latencies, no timeouts, no waiting.

mpd-devel mailing list

Reply via email to