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 periodically. > 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. Max _______________________________________________ mpd-devel mailing list mpd-devel@musicpd.org http://mailman.blarg.de/listinfo/mpd-devel
