Current impl fetches pl, purge pl items, fetch RSS, inserts entries. If the RSS
fetch fails (remote server is temporary unreachable) the playlistitems for that
RSS are all dropped.
This has a side effect that RSS playlists cannot be determined from tracks (see
issue #1126) and thus cannot be deleted.
Simple fix to defer playlist item purge to the point that the RSS fetch is ok
and before the inserts
Previously we just sent packets when ready, which especially during startup
meant a largish number of packets got sent rapidly. This seemed to cause audio
glitches. With this change the rate is adapted to follow ACKs from the device,
which is more in line with Chromium's way, though still far from the same.
Also added capability to resend packets when a nACK is received.
Also some wip attempts at sending coverart as VP8 video.
For unknown reasons some Chromecast devices disconnect causing a TLS error if
we don't OFFER a video stream. Seems actually sending video isn't required to
fix the issue.
The non-timerfd code path depends on SIGALRM being defined, so signal.h
always needs to be included.
This allows forked-daapd to build and run on NetBSD and probably other
BSD systems too.
This is an attempt to be nice to peers, so that we don't make many similar
requests to e.g. Discogs. This could happen via proces_items() for an album
where we have the same artwork url for each track, and if it was 404 we
would continue attempting the same request for each track.
With the new speaker selection philosophy we aim to preserve user choice, so we
shouldn't unselect speakers just because they happen to be switched off when
the server is restarted.
The new field "random" is true for smart playlists with an order by
clause "random", otherwise it is false. This allows clients to handle
randomly generated playlists differently from static playlists.
The tracks of a smart playlist might change between library rescans.
Allowing them to be cached based on the last rescan timestamp
("Last-Modified" header in the response) leads to potentially showing
incorrect track listing if a cached version is used. Thus the response
for playlist tracks should never be cached by the browser (this is
achieved with setting "Cache-Control" header to "no-store").
