I have found something that looks like a bug in MPD:
- When a song is finished, the next one is played and the 'player'
event is emitted.
- When the client sends the status command just after this event, the
songid is the new one but the 'elapsed' time is not reseted to 0.
This is problem because I have implemented the solution using a timer
on client side to compute the elapsed time but with this bug the
elapsed time continues to be incremented on a new song.
assert_static() will help us to find false asserts in compile time. Of
course it only works in case of expressions which can be evaluated
compile time. It cannot be used in global scope.
When MPD quits in a non-clean way, the state file isn't written, and
on the next start, MPD time warps to the previous clean shutdown.
Save the state file every 5 minutes; this will probably be
configurable at a later time.
Note that we don't set a wakeup timer for that: when there is no MPD
traffic, MPD won't wake up to save the state file. This minor bug is
tolerated, because usually there is no change in MPD's state when the
main thread is idle.
If the caller attempts to seek only a few bytes forward, chances are
good that the offset is already in the buffer. In this case, simply
fast-forward the buffer.
If someone calls seek() with an invalid (negative) offset, the curl
implementation of that method returned false, but left this invalid
offset in input_stream.offset. Move the calculation to a temporary
variable.
While waiting for the input stream to become ready, ignore all
commands except STOP. This fixes seeking errors with (remote) songs
which the decoder has already finished.
skip_symlinks() expects an UTF-8 encoded file name, but
updateDirectory() passed ent->d_name (in file system encoding) to it.
Convert it to UTF-8 first.
HTTP servers respond with "416 Requested Range Not Satisfiable" when a
client attempts to seek to the end of the file. Catch this special
case in input_curl_seek(). This fixes a glitch in the ogg vorbis
decoder plugin.
Since we are using curl_multi_info_read() / CURLMSG_DONE for detecting
end-of-response, we can remove all running_handles==0 checks. For
some reason, that has never worked correctly.
curl_multi_info_read() is the authoritative source of the
"end-of-response" information. Always set c->eof when a CURLMSG_DONE
message is received, and check the result (success/failure) after
that.
