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>
(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"
Before the value in the db was not read straight into mfi->disabled and
pli->disabled, instead it was evaluated as != 0, so the ->disabled field
would just be true or false. This was also necessary when INOTIFY_FAKE_COOKIE
(1 << 32) was written to the DB, because it could not fit in the uint32 of
mfi->disabled/pli->disabled.
I consider this juggling poor practice, so with this change it is read straight
in and out, always as a int64.
- 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
The artwork db field should only be used to save media file artwork metadata,
which mostly means whether it has embedded artwork or not. It should not be
used to save where we found artwork for the file, since that is not static.
So this commit removes for instance ARTWORK_OWN, ARTWORK_DIR etc., which we
weren't using anyway.
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.
This adds a new timestamp value "db_modified" into the admin db table.
In addition to the existing "db_update" admin value, this value is also
updated if rating, play-/skip-count or seek changes for a
media_info_file (files db table).
This should improve the caching behavior in clients of the JSON API
(especially the player web interface) in refreshing its data if some of
this values changes.
