0012245: Artwork scanning improvements - MantisBT

ID	Project	Category	View Status	Date Submitted	Last Update

0012245	MMW 5	General	public	2014-10-21 07:26	2024-03-19 18:36

Reporter	jiri	Assigned To
Priority	immediate	Severity	minor	Reproducibility	always
Status	closed	Resolution	fixed

Summary	0012245: Artwork scanning improvements
Description	Currently it seems that there isn't any priority in which artwork of a track is stored in DB. It results in sometimes blurry (i.e. lo-res) versions of images shown, even though higher-res versions are available. I think that we should sort by Image type, where 'Cover (front)' and 'Not specified' would be both sorted first, but with resolution as a secondary criteria.
Tags	No tags attached.
Attached Files	image_search_order.jpg (67,368 bytes) image_search_order.jpg (67,368 bytes)

Fixed in build

related to	0013742	feedback	Ludek	Album Art: inaccessible artwork should be superceded by available artwork
related to	0014554	closed	Ludek	Issues while scanning picture folders
related to	0014918	closed	michal	Slow scan of files with >1 covers
related to	0014848	closed	michal	Album Art: In Image search window there is no way to preview found images in larger window
related to	0020686	closed	Ludek	Folder.jpg is not displayed, but other bitmap files from the same folder
related to	0020736	closed	Ludek	Artwork in file tags is listed as the last and not added to DB (regression against 5.0.4)

jiri 2015-04-16 08:40 administrator ~0042437	Increasing priority, since it should be trivial to implement and would be nice for the pre-release.

Ludek 2015-04-28 10:07 developer ~0042481	Fixed

rusty 2016-11-24 20:56 administrator ~0046248	I can't tell for certain whether this is resolved in 2040. The problem is that even now, there can be 15 identical images, but they're sorted in bunches by resolution. e.g. image 1 (low), image 1 high, image 1 very low, image 1 medium, image 1 high, image 1 very high I suppose that short of adding some algorithm to determine whether images are identical, this is the best we can do?

Ludek 2016-11-28 16:22 developer ~0046293 Last edited: 2016-11-28 16:28	Rusty, isn't this just survival from MM4 database? Note that this issue was about scanning _new_ content into library. So if I remove an album from library and re-scan it again to the library then the cover list for the same image types looks like this: 709707 i.e. 501263 pixels 800474 i.e. 379200 pixels 600600 i.e. 360000 pixels i.e. descending by (width height)

rusty 2016-11-29 20:20 administrator ~0046308	Maybe I'm misunderstanding the issue. What I mean is that the possible album art images that are returned don't appear to be sorted (see attached).

michal 2016-11-30 09:07 developer ~0046316 Last edited: 2016-11-30 09:08	I think the issue is about order of images already present in track, not about image search. Note, we display search results in the Google order, i.e. by relevance. In case we reorder them by resolution, it could lead to poor relevance.

jiri 2016-11-30 09:32 administrator ~0046318	Ok, it's a misunderstanding then, the original issue was about Artwork in DB, not online searches. As for the Searches, per IM discussion with Michal, we can't do much about it. Probably the only option would be to implement an image matching algorithm, but even this option has its issues (technical complexity, unclear priorities (larger not always better), ...). Setting as Resolved, since I don't see a solution and actually don't see it as a big problem. Please reopen with lower priority if needed.

peke 2018-07-14 01:18 developer ~0050753	Added relation to 0014848:0050478 where user can add few AA and decide later which one is correct (Point 3)

peke 2020-07-07 00:56 developer ~0058786	Verified 2259 I do not see a problem anymore.