* [db,jsonapi] case insensitive directory/file listing
* [jsonapi] file listing of playlist uses same VPATH ordering as per directory and files
* [db,jsonapi] sorting via existing S_VPATH
* [db] replace LOWER with COLLATE NOCASE
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.
The purpose of this is to support library backends making their own
calculation of these id's, which is relevant if they have more information
available than just album_artist and album.
This also removes a bunch of sqlite extension code plus some triggers, which
in itself is probably an improvement.
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.
If a file gets updated/rescanned we generally don't want to reset the above
values. This commit adds DB_FLAG_NO_ZERO, which marks a field so that
db_file_update() will only update it if the new value is non-zero (i.e. the
caller probably has a "better" value).
This change means that we will use album_artist even if compilation_artist
is configured, thus compilation_artist will only be used to override artist.
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.
The query did not respect the filter and therefor always returned the
number of albums in the library and not the number of albums for the
given query.