Using worker threads instead of httpd threads means that we, not libevent,
decide which requests get handled by which threads. This means that we can
make sure blocking requests (e.g. volume changes) don't get in the way of
realtime(ish) stuff like mp3 streaming.
Includes refactor of httpd_stream_file() since it was a bit of a monster.
- Remove playlist commands only used by libspotify: adding / removing
playlist command was used by the callbacks from libspotify to receive
incremental updates (did not work for some time)
- Remove "login" web api endpoint: no login into libspotify is required
any more. Spotify web api authorization follows the OAuth flow.
(db upgrade to v22.00)
`scan_kind` identifies the library "scanner" component that created the
item and is responsible to keep it up to date (rescan).
The library update now supports passing a `scan_kind` to update only the
items of one particular "scanner". This allows e. g. to only update the
item from the Spotify library or only update the RSS feeds.
The OwnTone database is upgraded to v22.00 and the `scan_kind` columns
in `files`, `playlists`, `directories` are identified by:
1. Check if item is part of a RSS playlist (podcast RSS feed), they
belong to the "rssscanner"
2. Check if item has a Spotify `virtual_path`, they belong to the
"spotifyscanner"
3. Remaining items belong to the "filescanner"
Select use of either libspotify or librespot-c as streaming backend via config
option.
librespot-c (renamed/improved spotifyc) impl has the following:
- sync interface
- seek support
- honor bitrate config, set client and thread name
- use web access token with "streaming" scope for login
- fix issue with podcast playback
Also say goodbye to file-based Spotify login.
- Use prepared statements
- Add qi_mfi_map that defines mapping between mfi, dbmfi and qi
- Use qi_cols_map/qi_mfi_map for iteration (avoid duplicating field references)
- Stick to "qi" as name for a queue_item in db.c (more similar to mfi/pli/gri)
- Some renaming and other minor stuff in db.c's queue code
This commit also changes db.c's sort_tag_create to always recreate sort tags,
so that they match source tags, should they have changed. Unclear to me why
the previous solution didn't do that, so will probably regret this change when
it dawns on me.
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").