Automatically read/write ratings to files in the library, if options read_rating/
write_rating are enabled. Also adds a max_rating so the user can set the rating
scale.
Doesn't sync automatic rating updates, because that could lead to whole-playlist
file rewriting.
Closes#1678
---------
Co-authored-by: whatdoineed2do/Ray <whatdoineed2do@nospam.gmail.com>
Co-authored-by: ejurgensen <espenjurgensen@gmail.com>
socket() with SOCK_NONBLOCK (O_NONBLOCK) seems not to be possible on MacOS, it
yields 'Protocol wrong type for socket'. Switch to using fcntl() and O_NONBLOCK
instead, hopefully works better cross-platform.
Closes#1644
mpd is based on evhttp, so if httpd should use another backend they need to be
decoupled. No need to use httpd_send_reply/error, since CORS headers are not
relevant to MPD artwork serving.
(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"
Misc refactoring, e.g. alignment of how modules save tracks and playlists, incl
use of mfi and pli. Also try to avoid direct calls between library and player.
Also changes relative seeking behavior:
- seeking behind the the current track only switches to the previous
track, if we are not more than 3 seconds into the current track,
otherwise starts current track from the beginning
- seeking beyond the current track will start the next track from the
beginning
The previous solution would use subqueries to count the number of items and
streams in each playlist, which means that response time gets pretty slow if
there are many playlists.
This commit also includes a number of lesser db code changes.
Instead of asking a client to first scan the path into a media_file_info
object and afterwards add it to the queue, we now offer a library
function to directly add a path.
The library-source that can handle the given path translates the path
into new queue item(s) and adds them to the queue.
Before, we returned either unordered (for RSP, meaning client had to
sort) or ordered by a client selected sort_clause[]. The latter are
multi-purpose and therefore not optimised for browse queries.
To speed up, we predefine the entire set of browse queries, including
order, with matching indices. The predefined queries are used except
if the client explicitly requests a non-default order or query.
As a special bonus, the commit also allows queries with I_SUB that
have an offset but no limit.
The noidle command did not prevent idle events to be sent to the client
directly when they occured. This resulted e. g. in M.A.L.P. in errors
trying to play an album from the library)
