[Feature] Clarify search results on the search page

[xxxserxxx]

c.f. the thread in the song search issue, the Subsonic API does not clearly define how servers should implement search3. Two changes:

1. retitle the colums on the search page to "artist matches", "album matches", and "song matches"
2. One of the solutions below

Details:

search3 returns a searchResults3 that contains a structure that has an array of artist, an array of album, and an array of song: these are the elements returned as search results, grouped by type. However, the API documentation says only that the server should "search in the IDv3 tags" -- but not which tags, or how results are grouped.

Gonic puts all the artists who's name matched in the artist array, and all the albums and songs whose titles matched the query in the album and artist arrays. Navidrome, on the other hand, matches across several fields of metadata and includes any such matches in the arrays. This means that a query for "XYZ" will include a song titled "ABC" by author "XYZ" in the song array.

Solution 1

Add a "why" label at the page bottom, and when an item is selected, print the IDv3 tag name and value that caused the match. If there are multiple tag matches, show the first.

The benefit is that search3 would show the same results in stmps as it does in Navidrome. The con is that many, many songs who are only peripheral matches because of their album titles or authors will be in the song column.

Solution 2

Emulate gonic's search3 logic, and only show name/title matches, such that every item in every column will contain the query term.

The pro to this approach is a more focused search results, where every result is a direct match, and duplicates are reduced. The con is that the client might have to make several sequential paging calls to the server to get enough content to fill the columns.

Right now, the code uses the default paging: 20 of each type of thing. The user presses n to fetch the next page of things. With gonic, this is a single call every time: 20 or fewer more of each thing is fetched with each call. With Navidrome, several pages of songs who only matched because they're in albums who's titles matched could be returned; if we're only listing songs in the song column whose titles match the query, then several calls to Navidrome might need to be made. It would be unacceptable to have nothing be added when the user presses n, since they wouldn't realize that there could be more.

SER

I believe solution 2 is tighter, clearer, and reduces result clutter.

[xxxserxxx]

Since search is already merged, and since it behaves poorly for Navidrome, I'd like these enhancements for v1.0.0