hass-music-assistant
hass-music-assistant copied to clipboard
music-assistant
Searches may return duplicates by accident
What version of Music Assistant has the issue?
2022.8.1
The problem
After fixing a duplicate artist result I noticed that the artist search still would return results that contained duplicates as well as incorrect results.
How to reproduce
Artist search : 'weird'
Initially return :
doing a backspace and re-adding the last letter appears to give the expected results :
The results in this screenshot are correct. due to a slight spelling error in the artist name between Spotify and local file system ( https://github.com/music-assistant/hass-music-assistant/issues/811 )
Artist search : 'salt'
backspace and adding last letter again :
The results are not easy to reproduce, which suggests some kind of timing issue when processing the search text. The second example appears to suggest that I'm getting two search results ('sal' and 'salt') as the final display result.
Relevant log output
No response
Additional information
Could a 'delay' in processing the searches be the solution ? Typing speed appears to matter in the reproduction of this issue.
What version of Home Assistant Core are your running
2022.8.1
What type of installation are you running?
Home Assistant OS
On what type of hardware are you running?
Generic x86-64 (e.g. Intel NUC)
Thanks for the report. Where you have written “second example” I think you mean “first example”?
the 'weird' search is my first example and the 'salt' search is my second example. The fact that 'Salma hayek' and 'Saliva' are listed when the search should be for 'salt'. To me this suggests that I'm getting results from the search for 'sal' as well as results from the search for 'salt'
I don't have any artists with 'weir' in their names, but I suspect I'd be seeing those as 'additional' results. This is why the second example (with 'salt' as a search text) may be a better testcase to find the source of the problem.
All of this depends on what artists are available in your library ...
Marcel says this can be fixed but is a low priority. Thanks for reporting it. This will remain open until fixed.
update : beta v2b1 : same issue still present.
Speed of input appears to have an effect on these 'duplicates'. An interval of > 500ms between input of letters appears to be enough to stop it. Very tricky to reproduce as there may be some caching involved ?
The two "Weird al Yankovic" results are related to the fact that there are different quotation marks in the name of that artist, which means that on a technical level they are separate results. This appears to be the result of Spotify using alternate naming convention compared to the one I got from Music Brainz Picard in my own files.
On your second point I am about to open an issue regarding linking and minor things such as different quotation marks shouldn’t stop the link.
v2b29
I'm seeing duplicate result, but only in the 'total' and 'artist' views
Also worth noting is that there is no artist image for Salt-n-Pepa in that view
I suspect one of the duplicates is the Spotify and the other is the smb-provider artist result ?
That might explain the different artist image pictures.
Behaviour is much more consistent and repeatable compared to v1. I'm not sure why some of the results are listed though. I've got multiple albums/tracks for both artists ... so I'm not sure why the others aren't showing.
Mostly that looks like expected results given the linking issues. Although I see Radiohead there in the artist view which looks wrong?
you'd think that, right ?
So I dig deeper ... and it is technically correct, because they've got a track with "weird" in the title :
So Radiohead (artist) gets listed because of an album which has a tracik ...
At least that appears to be how it got into the results. In a way the search is even better than you'd think it is based on the results that are given in a category. Consider the fact that it's giving me results across 64372 tracks in a matter of seconds that is incredibly good.
edit Just checked the Spotify search ... it's giving me the same results. So what is happening is this : (1) search results from the smb-provider (resulting in 'weird al' artist + my image) (2) search results from spotify provider (resulting in 'weird al' artist + their image)
Proof :
The 'missing' results would be the podcasts and the "Featuring artist" results I'm seeing in Spotify.
Maybe we need an option to do a strictly 'local' search so the artist results aren't "duplicated" ? Another possibility would be to add a classification that explains the source of the result.
I personally don’t think that is right as you have selected Artist. Just because they have an album with that word doesn’t seem right to me. And it is the same Artist (weird Al) so it should be linked.
MA does link to the Spotify album/track/artist entry in the album view (it doesn't do the same for file provider due to limitations). I'd argue that the search results should allow for both types of link. So one link to the entry within the MA library and one to the provider-specific location (if possible).
I doubt anything can be done about the Spotify search results, because it doesn't appear to allow for artist-only searches in the app either. I don't know if the API for Spotify has the same limitations.
I do agree that 'Radiohead' is a very odd artist result, but unless we can specify/exclude album/track/artist/playlists as categories there isn't anything that can be done to fix this.
I'm not sure I understand what you are written. As I understand how MA work the "MA library" is a pointer (if you will) to the music you have on different providers. Where it can be established that the pointer to two providers is the same thing then that is collapsed in the interface to show just one and when playing back MA chooses the highest quality. So where you say
I'd argue that the search results should allow for both types of link.
I don't think that is true. MA, by design, should show only one entry ON THE MAIN PAGES for the same album/artist/track otherwise people could see up to seven entries if they had all of the current providers. The icons show that you have that thing from multiple providers. Then you can go to SHOW INFO for even greater detail. The difficulty is deciding that the thing is actually the same. Its easy if the provider supplies a unique identifier like MB ID or ISRC but not all providers do.
Radiohead I think is straight forward. "Weird" isn't in the name so it should not appear on the ARTIST view. On TOP RESULT yes it could appear as it is searching across all tags for those letters.
But we are digressing from your original issue. That being typing fast results in duplicates. This linking discussion should be in my other issue. And probably the Radiohead search result should be a discussion to see if it is expected behaviour or not.
MA v2 beta 29 has two 'search' / filter options. The global search (left hand menu) is functioning as it should.
It's the 'filter' at the artist / album /track level (the icon top right of the view) that appears to have inconsistent results. This appears to be linked to the speed of entry. Typing slowly has the best results / best behaviour. Speeding up results in odd behaviour.
Example 'weird' :
switching to list view appears to remove the duplicate entries :
Second attempt : 'salt'
Also worth noting is the empty rows in the result set.
Work-around / reproduction = After each key-stroke a wait-indicator appears = if you hit a key before it has dissappeared the results will be inconsistent = if you wait until the 'wait indicator' icon is gone the results are at their best
can you re-check this one with b59 ? At least the library now better handles this but I may also have to adjust the frontend
v2b59 I can't replicate it like I used to by typing search terms as fast as possible. As such I think it's fixed. I hope other users can confirm this as well.
It would be nice to have the provider-icons also visible in the grid-view as the results appear to be separate by provider, but the list-view is a more useful view so this is a not really an issue worth fixing.