Repository navigation
Conversation
|
in fast mode, there's some filtering of artists/albums that may have diacritic marks or different spaces in their names. i'm adding additional normalization to catch those instances. where things get harder is non-latin scripts like japanese/korean/chinese, since the artist listing in lidarr may vary substantially from how the artist is listed in tidal. i made a simple attempt to solve this: if artist fails, match on album name only. this will result in some junk results being included, but not a ton. alternatively, you could trust the tidal results to be ordered by relevance and just take the top N and always include them before filtering the rest. but i tried this and the v1 api results are really quite garbage and not sorted well. for people with a high amount of non-latin script libraries, comprehensive is the better choice for now unless/until someone wants to write a thorough cross-script normalization strategy. it would be a lot of work. a couple of test artist:albums resolved by this change: etienne de crecy - warm up i also added additional normalization to deal with tidal's completely inconsistent album edition tagging. they sometimes use brackets, sometimes parentheses, sometimes even braces, to mark an album as "deluxe" or "extended" or whatever. again this only applies in fast mode, not comprehensive. |
the tidal API returns a tremendous amount of irrelevant results as it does loose fuzzy matching. as a result the plugin often spends a lot of excessive work looking up albums for individual tracks.
this PR drastically improves performance and reduces the long-tail of irrelevant results that are inserted into the interactive search results.
there is a new indexer config setting for search strategy. "fast" is a new default setting that reduces api calls significantly, by requesting fewer records to begin with as well as limiting track result lookups. i'm not sure the edge case that track results solve, maybe singles(?), but the "fast" setting limits the number of track results that will be honored and enriched in the tidal result object to 10. this setting also does some loose string matching to discard results that don't match the artist name or album naem as expected. the alternative setting, "conservative", is very similar to the old behavior. up to 300 results will be pulled from tidal and all track results will be resolved back into albums, which can be slow and noisy. but i want to make sure users can go back to the old behavior if they find problems.
trace logging can be enabled to view which albums are being filtered from tidal search results based on the string matching in IsRelevantMatch. i think there may be artist name mismatches between what lidarr is using (from musicbrainz) and what tidal is using, but i don't have any concrete examples right now. should these occur, setting the search strategy back to "conservative" will resolve it and we can investigate fixing the matching strategy in the fast path.