When pipe playback is started, but no data is written to the pipe, the input
loop would bring the cpu to 100%. This fix limits the loop like it was before
player refactor.
Since it is unknown how to do real sync on Chromecast, this commit instead adds
a primitive delay to the stream, so that it is at least somewhat closer to
Airplay/local audio.
Also some cleanup of unused stuff.
* [db,jsonapi] case insensitive directory/file listing
* [jsonapi] file listing of playlist uses same VPATH ordering as per directory and files
* [db,jsonapi] sorting via existing S_VPATH
* [db] replace LOWER with COLLATE NOCASE
pb_suspend() + pb_resume() during track changes made the playback status
incorrect, i.e. pb_session.source_list/playing_now would not match what the
input was actually writing. This attempts to solve it by resetting the
session when pb_suspend() is called, so that the input, input_buffer and
source_list come into sync.
If playback was paused during the very last part of the track, the rest of the
track would be read into the input buffer and the input would be closed. With
this commit the input will not be reopened.
Also allow input_flush to be called with null argument.
Fixes bugs which were due to incorrect handling of unsigned integer wrap-around:
1. Calling packet_resend() with seqnum + len greater than UINT16_MAX => infinite loop
2. Calling rtp_packet_get() with session->seqnum - seqnum greater than pktbuf_next => wrong packet
This fixes a bug from commit 37ce8dd6 where seek_http (which is called when
pausing playback) for non-seekable streams would return -1, thus signalling
an error, even though it is not. The player would think that the stream
could not be played and then skip to the next item.
The fix in commit 3928ab6 broke resuming from an underrun, since it meant that
pb_resume() would flush the input buffer. With this fix it is possible to call
input_resume(), which will not flush the buffer if the source is already open.
Also renamed some functions in player.c for consistency.
For dates that require context (ie today, yesterday, N days ago etc) we want the
underlying SQL to respect the current time when running query; a query that
requests items for 'today' should only find matches for the time it was run.
Current implementation would generated a fixed date (at the time the SMARTPL is
inserted into db) in the playlist table where as this commit understands the
context of the date.
