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.
The constraints on songalbumid and songartistid where changed with v20, so we
need to make sure they take effect when upgrading.
This commit tries to do the table recreation like sqlite recommends and without
manually crafted copy queries that are probably prone to errors.
Since we are recreating anyway, this commit also reorders the columns slightly.
It also includes auto-drop/recreation of triggers (should really have been its
own commit) during upgrade, like is already done with indices.
The idea here is to make sure the fixing up of tags is done in a consistent
manner. For strings, this means stuff like trimming and empty strings -> null
are applied the same unless there are special exception rules set. It also
means that defaults are applied the same across structs, e.g. "Unknown artist"
for both mfi->artist and queue_item->artist.
The change is also necessary because we want to remove trimming from the sql
query and instead implement it ourselves.
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.
