funny how they're trying to deprecate daemon() in favour of the mess of posix_spawn and still don't provide genuinely useful stuff like SOCK_CLOEXEC, NONBLOCK and pipe2(2).

This is to help amused-web. Change the ctl to send an extra STATUS after a MODE change to preserve the behaviour.

Not sure how it worked with libevent before, but the reschedule is wrong. We need to schedule a timer to re-add the event on the listening fd.

libevent is a very cool library, I like its APIs and enjoy using it. However, for amused it is maybe a bit too much since it doesn't deal with too many file descriptors. Amused only needs to monitor one fd for the player process and the currently connected clients. Given that it runs per-user locally, having more than a dozen of fds open is very, very rare.

used @openbsd.org initially by mistake and got copied around in most files. Since this has nothing to do officially with the OpenBSD project, use my own email address.

The monitor mode now has access to some additional information other than just the name of the event. The `mode' and `seek' events now report the mode status and the position/duration respectively, allowing consumers of `amused monitor' to show correct and coherent information. It helps in particular applications like `amused-monitor' (in contrib/) that show a progress bar for the current song. Before, they had to run their own timers and periodically synchronize using `amused status', now they can just update the state in the same `amused-monitor' event loop.

the consume mode implicitly drops the tracks from the playlist when played 'till the end (note that skipping over a track doesn't trigger the consume mode - yet?)

rethink a bit which event are reported and when. - drop 'toggle' event as it's not useful; now 'amused toggle' will report the play/pause event. - replace 'flush' with 'load'. there's no real difference between a flush and an empty load. (also, less event the better) - some events (next/prev/jump) are reported earlier to avoid possible issues (when messing around with the playing queue we can end up in every possible state.) - report 'seek' only after it really happened (i.e. after the player process sent the new position.) There's still a possible race here (we can receive a previous IMSG_POS and think it's the reply to the seek) but it it's hard/impossible to work around. - drop 'restart'. we have 'seek' now which is better (and actually restart is implemented on top of seek.) - add 'seek' to the default list of events.

it's awkward to call it with the address of the imsgev struct inside the ctl_conn struct. Just relay the info to every client in monitor mode. After all, if a client is in monitor mode *and* issues commands, it's not strange that they're echoed back (note that this is currently impossible, the command line client can either issue commands or be in monitor mode.)

I've added a sufficient amount of code I guess