View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013727 | MMW 5 | Track Browser | public | 2016-12-08 19:15 | 2024-10-11 17:00 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Fixed in Version | 5.0 | ||||
| Summary | 0013727: Most views are missing artwork | ||||
| Description | When first-time users run MM5, their experience is that Artist images are almost always black, and missing album art remains blank even if MM5 is configured to look up artwork. We've discussed this before, but I can't seem to find a bug for this. The issue re. Artists was raised at 0013579 (item 3), however, I'm again raising these issues in a separate bug because I think that we should fix this 'immediately' so that first-time users get a better experience. i.e. 1) Search for missing artwork should be enabled by default (so that Artist images and Album art are looked up automatically) 2) The trigger to activate such searches shouldn't be limited to visiting a particular artist or a particular album, but rather: - Images in the root nodes should always be looked up (i.e. in Home, Music, etc.) - Images should be looked up in the background (rate constrained) so that the situation doesn't persist for too long, with greater priority given to those in an active view. - Artist images should should be looked up | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2077 | ||||
|
|
Per IM discussion assigned to Michal to implement the Artist images part. In order to limit servers usage, only the visible part of any view will be looked up (not 1000s of artists in Artists view, unless user scrolls). As for Albums, deferring. It isn't clean whether it's a good idea to implement at all in automatic way. Many albums probably already have Artwork and those that don't would better be auto-tagged from MB (to be implemented soon). |
|
|
Automatic artist image search implemented in build 2045. |
|
|
Seems to be ok, at least for now, assigning to Rusty to review and note thoughts re. Albums. |
|
|
Tested 2045 and Artist image lookups generally work well. Main issues are: 1) After art is loaded and the user scrolls up and down, many of the images appear with broken links (see attached). 2) Many of the images are of Albums rather than of the Artist. I wonder whether it's possible to modify the search to use artists. 3) It would be preferable if users would cache the image to the MM Server so that there aren't repeated lookups via Google. |
|
|
1) I cannot reproduce in such quantity and with these steps. But sometimes image search could return HTML instead of image and this leads to broken image too, will look at this. 2) I am not sure, how can we achieve better results. We search preferably for square images, they look better in GUI and improve relevance, but could lead sometimes to album images. 3) I don't think it is good idea, Google servers are prepared for very big load, our server will never be. And we need its capacity for MB DB requests. We could use MB DB for image search too (i.e. search for every artist and fetch link to artists image, if present in MB DB), but I am afraid of server overload. |
|
|
2) Note also that a relevant album cover can often be a pretty good artist image, maybe even the best available. 3) Another aspect is copyright, storage of arbitrary imagery from web on our server doesn't look like a good idea. |
|
|
2) I'm not sure the best way to solve this, but here are examples of Artwork that is correct in MusicBee but not in MM5 (along with some ideas: Aardvarck - MM5 shows an album. I suspect that MusicBee is using Discogs or Wikipedia or allmusic to find Artist images. OR they search for Aardvarck "musical artist" (though that doesn't work well for the ABC example below). ABC - MM5 shows ABC logo! See above. Note: based on this example ( https://musicbrainz.org/artist/87199477-b0df-4ead-84ee-9b54b4abfc3d/relationships ) Discogs and Last.fm have the best images, though that's probably not universally true. Which makes me wonder if perhaps the MM5 database should retain a list of the best images (as determined by those that users most often choose manually). "àééì âåìï" - shows a picture, Musicbee is blank. For items like this that have no obvious matches in any well known DB, the Artist should remain blank -- that's preferable to filling it in with incorrect images. Agaric - shows a mushroom (even though e.g. Discogs has an image of him). Alan Parsons Project - shows an album even though there are plenty of images of the band members. Alicia Keys ft. Nicki Minaj - shows an album. Perhaps text after ft. should be ignored? 3) Agreed. An alternate approach is to: a) limit the speed of lookups (e.g. 1/s) b) rotate lookups between different sites (Discogs/Wikipedia/etc.). c) as suggested above, have the MM db retain a list of links to the best images. |
|
|
2) a) re. Discogs or Last.fm - I don't think we can use it for free. b) re. Wikipedia - It has better matches, but often lower quality images than can generally be found online. c) We'll try to remove the square images preference, hopefully it'll help in some case. d) We probably could add to look up table for specific cases in order to know what to look for - i.e. which search term should be used for particular Artist, at least for the better known. e) Removing 'ft.' and some other tweaks could be used. So, in general, we can work on improvements, but I'd decrease priority after the obvious fixes, since this is rather about long term improvements. |
|
|
2d) we already use some artist search term mapping for some artists. There is probably no general manual for this, every artist needs individual approach, based on its specific name. Sometimes help quotes, sometimes "+band", sometimes "+singer", sometimes, "-tribute", etc... |
|
|
Square image limitation for artist image search removed in build 2048. re 2) we cannot guess, what is "not obvious match" and what is not. Google returns some image nearly for anything, without any match score. Artists with names like "Agaric" will be always problematic, Agaric definitely is mushroom :). Even when searched manually I cannot find anything relevant, I have no idea what could be correct and what is not. I think it is up to user, use our image search dialog in such cases, and found something more relevant manually. The only solution is to find some query, that returns better results, and extend our mapping table for such artists. |
|
|
2)a) Discogs does allow its service to be used. See: https://www.discogs.com/developers/ b) Also, unless i'm misunderstanding, last.fm allows this as well: http://www.last.fm/api/show/artist.getInfo |
|
|
Michal will try to use Discogs. |
|
|
In build 2051, Artist images are not loading at all (i.e. in the Music/Home/Artist etc. views -- it still loads in Artist > ArtistName views). Was it intentionally disabled until Discogs is implemented? |
|
|
No, it was regression, automatic image search could not be set. Fixed in build 2052, and it will be default true now. |
|
|
Artist searching using Discogs implemented in build 2059. Resolving, so you can test. Note, downloading from Discogs can be slower (comparing to Google) and they sometimes can stop returning results for some time, because of their request rate limits. There should be limit 240 requests per minute per IP address (based on their documentation, MM5 take this into consideration and does not make more requests), but, according to their forum, there seem to be also some undocumented other limits, which sometimes affect queries. We use Google search in case Discogs searching/downloading fails. |
|
|
Tested 2076, and I'm noticing a couple of things: 4) When navigating to a particular page of Music > Artists that is missing all artwork, MM5 will not update the artwork at all. The artwork will only occasionally update after scrolling to the location again to refresh the view. 5) When navigating to Music > Artists > ArtistName , the artist artwork fails to load (in contrast for Music > Albums > AlbumName, the album loads a second after the view opens). 6) There is nothing indicating that artwork is being looked up in the background, and so users are likely to think that auto-lookup functionality is broken (in fact the images _are_ being looked up, but the view isn't being updated). All of this is better viewed in this video: https://www.screencast.com/t/KtzIBCHQO4s6 Debug log attached. |
|
|
Regressions fixed in build 2077. |
|
|
Verified 2078 |
