Commits
- Commit:
e87b9802208746b0a6fa58f3683a16f8a2e7ab98
- From:
- Omar Polo <op@omarpolo.com>
- Date:
CHANGES for 0.7
- Commit:
b0d2a96623a89cfe946be257db54d6099b394da8
- From:
- Omar Polo <op@omarpolo.com>
- Date:
tweak -d description
- Commit:
500432f1a3a0f9ab14241388c9220c5c29ce0cf5
- From:
- Omar Polo <op@omarpolo.com>
- Date:
typo
- Commit:
926ee8364e8c83d7a22dcd5bceb65e235486703a
- From:
- Omar Polo <op@omarpolo.com>
- Date:
consume all enqueued messages before calling imsg_read
player_dispatch reads only one imsg from the ibuf. Next time it's
called, the other messages on the ibuf (if any) are discarded and new
ones are read. This can cause the player process to go out-of-sync with
the main process if multiple messages were "bundled" in the same chunk.
To avoid this, always try to imsg_read before. If it succeedes, we read
process the equeued messages one by one, if it fails then we poll for
new data and call imsg_read to process them and retry.
This fixes a bug where amused could be "confused" by running
$ amused pause ; amused stop ; amused play
in a loop a few times. This bug and the repro were reported two months
ago by Dirk-Wilhelm Peters, thanks! (and sorry it took so long to
understand and fix the issue)
- Commit:
fc4a38afafeec3a23f264e76659b3405d2d7cc48
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't set the imsg fd as blocking mode
just do a poll before imsg_read in player_disptach to wait for data to
read. It's not performance-critical code, so this is fine.
If it were important not to do an extra poll(2), for example when we're
called is called after player_pendingimsg we already know there's
something to read, we could move the polling in the case `n == 0' below.
- Commit:
90122a37e6f55f08fd979f7b07ba20a49952faf8
- From:
- Omar Polo <op@omarpolo.com>
- Date:
amused monitor: allow to pass a list of event as filter
it's easier / simpler for scripts to do
$ amused monitor next,prev,jump
rather than
$ amused monitor | egrep --line-buffered 'next|prev|jump'
- Commit:
26caf091b4db3116bc2cb0205f4fa1e8a5fdbcae
- From:
- Omar Polo <op@omarpolo.com>
- Date:
use normal width for listing
- Commit:
7733d9b75cd487cf327c88d68067a2134e54d3f2
- From:
- Omar Polo <op@omarpolo.com>
- Date:
bump version number
- Commit:
801c4a4292aa76b16fcb13204bde322a27741a38
- From:
- Omar Polo <op@omarpolo.com>
- Date:
CHANGES for 0.6
- Commit:
072467856bbc068cc7b0a978ebf98fcdb9f03691
- From:
- Omar Polo <op@omarpolo.com>
- Date:
fix version
- Commit:
a6d90fb2a2388f8dac656580763603d3d5800862
- From:
- Omar Polo <op@omarpolo.com>
- Date:
manpage tweaks
- Commit:
5d86bc14239778053daa5c38c13f2a5c7d63a24c
- From:
- Omar Polo <op@omarpolo.com>
- Date:
simplify main_send_player: data is always NULL
- Commit:
a975dca965d92cd6af18a82629b597668e1d69d8
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't send the song' path to the player process
we're not relying anymore on the file extension, so this information is
useless for the player.
- Commit:
a7c21102d5a00f25af27b4f7ba894065aa28bb5f
- From:
- Omar Polo <op@omarpolo.com>
- Date:
we have no bugs :)
- Commit:
239029b61f575847650021a5b4904ed426a2e9e4
- From:
- Omar Polo <op@omarpolo.com>
- Date:
don't call player_sendeof on IMSG_STOP
the refactoring introduced this error where we call report an EOF upon
IMSG_STOP, making the player infinitely loop.