[API Request] Start discussion about all the filtering enhancement for the new data

[Tolriq]

Type of change

API extension

Proposal description

This is a discussion start to know what the clients needs / wants to enhance filtering in most of the queries to filter on the newly added data.
I personally do all the filtering at the client side and not via the API so clients needs to express their needs.

Backward compatibility impact

No response

Backward compatibility

• No backward compatibility impact.

API details

TBD.

Security impacts

No response

Potential issues

No response

Alternative solutions

No response

[dweymouth]

For me, the biggest thing would be to allow sorting and filtering at the same time for the getAlbumList(2) APIs. This can be done just as an API clarification rather than any actual schema change by just removing this language from the documentation about the type parameter:

Since 1.10.1 you can use byYear and byGenre to list albums in a given year range or genre.

In other words, allow the fromYear, toYear, and genre fields to be set and used without requiring that type (ie the sort order) is set to byYear or byGenre, and it could be set to something like recent instead. E.g. getAlbumList2 with type=recent, genre="Classical", fromYear=2000 would mean return all Classical albums in the library released since the year 2000, ordered by most recently added.

It would also be nice to add some additional filtering fields minRating maxRating and isStarred.

And this could perhaps be a separate discussion, but we should add a new getSongList(2) API(s) that works the same way as getAlbumList(2), allowing for a paginated, sorted and filtered list of all songs in the library. (After doing this we could also deprecate the getSongsByGenre API since it would be the same thing as getSongList with type=random, genre=foo)

[Tolriq]

Yes getSongList is mandatory also for offline first app to avoid using search3 to sync songs. And could lead to performance increase for the servers that have not optimal paging code.

[dweymouth]

As an aside, while sorting and filtering are closely linked, I think it's sorting where we need to really make sure to get it right. "Online-first" clients that don't maintain their own synced DB can still do client-side filtering by streaming the paginated APIs through a filter function and discarding the non-matching results, but clients can't implement their own sort orders without requesting the entire catalog ahead of time.

[Tolriq]

List all your missing use cases.

[dweymouth]

• Applying a sort order and filter to getAlbumList at the same time, as discussed above
• Ability to specify ascending or descending sort orders (new parameter to getAlbumList2 API?)
• Ability to sort the results returned by the new getSongList API by any of the following - title, artist, album, duration (time), year, date added, user rating, play count; ascending or descending. And less necessary but still nice to have - by bitrate, file size, file path

[jeffvli]

My use cases are basically the same as @dweymouth except with also an option for the total record count of the filter.

An additional enhancement (not sure how difficult it would be for servers to implement) is allowing for advanced querying using (nested) filter groups with AND and OR.

That way users would be able to query something like:

OR:
  AND:
    - Release year [equals] 2000
    - Rating [greater than] 3
  AND:
   - Release year [equals] 2010
   - Genre [equals] Rock

Some examples of this includes:

• Navidrome's smart playlists -- except this would be real-time filtering instead of adding all matches to a playlist
• Plex's advanced filters
• I believe Symfonium also has a native implementation of this with its offline database so maybe @Tolriq you can provide some information on how this can be best implemented?

[Tolriq]

My implementation is very specific for my usage, but the hard part is not defining the filters it's building the engine that generate the queries from them :)

Just a Json with a list of filter groups and a merge rule (and / or) and groups are a list of rules with a merge rule (and /or) and rules are simply field / operator / value.

[jeffvli]

Yeah disregarding the implementation details, I guess the main question would be to the server maintainers to see if they are willing to implement this type of filtering.

[epoupon]

This kind of filter is indeed quite difficult to implement properly and efficiently.
Simple AND filters like proposed by @dweymouth with more sorting options should be quite easy to implement for servers and should cover most use cases.