Bugzilla – Bug 9919
Rethink artwork
Last modified: 2011-03-14 12:44:29 UTC
Artwork needs a complete rethink. Some ideas: Scanner should scan every piece of 'media', including image files. Store these in the database just like audio files. Link from album/track to image(s). This way you could display many images for a single album, such as liner notes, back image, etc.
(In reply to comment #0) > Scanner should scan every piece of 'media', including image files. > Store these in the database just like audio files. Having that capability would be great, but there will need to be options that can direct the scanner in what and what not to scan. For images, you'd want at least the following selections: [ ] All images [x] Cover artwork only [ ] None (see bug 10429) You also then need to distinguish between cover artwork (to be use when browsing and in Now Playing) and any other images that may exist in the folder. The current option listing file names for cover art probably suffices. In the database, mark one image as 'cover' or 'primary' for both tracks and albums. And some type of option such as: [ ] When cover art is missing, use first image in folder This would tell the scanner whether or not to use another image from the folder as the cover when one of the listed file names (or embedded art) cannot be found.
To keep it simple, the scanner should: * Scan all images * Use the current filename matches (cover thumb album folder) as the cover image if available. Maybe not 'thumb'... * Default to the first alphabetical image if no filename matched. * UI should provide some way to view the other images.
Just as some people don't want the overhead of the scanner cataloging and creating thumbnails of any of their artwork, they should also be able to opt out of scanning all the miscellaneous image files that are in your music directory, giving them essentially the current behavior. > Default to the first alphabetical image if no filename matched. That could be ugly without some way to turn it off. You have no idea what people have stored in their folders.
this bug has the keyword, but this isn't listed as a block on 8303? personally, i would suggest that if no art is found under the predetermined assigned names, then it should use the BIGGEST artwork file it finds, ie. in KB size. that way it would use the largest and presumably highest resolution / highest quality one.
How about adding 5881 into this bug as well? https://bugs-archive.lyrion.org/show_bug.cgi?id=5881
*** Bug 11365 has been marked as a duplicate of this bug. ***
*** Bug 9385 has been marked as a duplicate of this bug. ***
Moving 7.4 bugs to 8.0.
One thing that needs to happen as part of this is some normalisation of the DB and the associated cache items I suspect that most users have 1 piece of artwork per album: the cover. At the moment if I have 1 piece of artwork for an album it will be cached once per track (at each size that is used, or precached). There isn't really a need to cache any artwork item more than once at each size if the DB is better normalised. Can I please request that this is fixed before more features are added? :-)
I don't fully understand what the issue that needs fixing is. You do have an album artwork track so whenever a client wants to use only one it can do so. OK, it would be more convenient if on a track you could find out whether two images are identical so you can show the one exception to that rule you have but that isn't a fundamental issue, isn't it?
i don't mind adding some features... but the main problem i see trying to be addressed here is when you have artwork that isn't named the way SC wants it. in my personal case, i'd like SC to look only for these two things, and nothing else, and i wish i could control it that way via options: 1. use Folder.jpg and only Folder.jpg as the source image for all albums, (and grant SC the priv of resampling/resizing/caching) 2. if Folder.jpg is not found, then use the BIGGEST RESOLUTION image file in the dir, if one exists. in addition, i'd like the ability to scan ONLY for artwork, and scan but IGNORING artwork. i know mherger said u can go deep into options and turn off caching, but thats not what i want. i want to be able to pick those kinds of art only/no art scans right where you manually tell SC to scan your music.
in addition to what i just said, i want to further clarify that what i meant above is that i wish i could tell SC not to look for other "pre-ranked" filenames EVEN WHEN Folder.jpg is missing. it just makes the scan take longer. if it is missing, it should simply use whatever biggest res file is there, if any. going thru a pre-ranking before or after Folder.jpg is just a waste of time in my case, and potentially worse if it uses "albumartsmall.jpg" which i NEVER want used UNLESS, and only if, Folder.jpg is missing AND its the biggest one in there, (unlikely but not impossible).
The problem that I have is that SC appears to allocate the first image that it finds as the album art. This leads to the following problem: - folder.jpg is present - also, each track contains an embedded image - SC uses the image from Track 1 as the album art :( What I'm looking for is a solution which gives priority to folder.jpg (or other recognised filename) as the album art so that the album art displays when browsing by album (which SC current does not), and also allows the display of the embedded track image when playing (which SC currently does). Sounds straighforward to me - but what do I know. If the change needs to be wrapped up in some larger change, then so be it... Kind regards
(In reply to comment #10) > I don't fully understand what the issue that needs fixing is. > You do have an album artwork track so whenever a client wants to use only one > it can do so. The problem is that I have over 9000 songs on about 700 albums. This means I only have 700 pieces of artwork, so I would prefer to only cache 700 items, at each size. Last time I checked SC would cache 9000 items at each size. The biggest cache items I have (186x186 PNG for controller) currently consume 80KB each. If they're cached once per album then that consumes a modest 56MB. However, if the image is cached for each track then just the images for that size consume 720MB. From a technical point-of-view there is absolutely no need to cache each image more than once. The database would look like: track(track_id, artwork_id) artwork(artwork_id, artwork_filename) However, last time I look it was something like: track(track_id, artwork_filename) and artwork_filename had the *track_id* encoded in it: music/9262/cover_186x186_o.png If there is only 1 piece of artwork per album then neither track_id nor artwork_filename need to encode track_id. All I am saying is that each piece of artwork should be cached only once at each size. That way when the controller displays thumbnails for the album it only needs to request one thumbnail. When it advances to the next track it already has the full-size image that it used for the previous track. Why not make artwork_id a hash of the original filename rather than the track-oriented filename requested by the controller? I run SC on an embedded box with a 4GB system disk. Cache space is limited... :-)
yep, i'd agree that an option to use folder art (if present) over embedded art should be included, for all the reasons said in the last two posts.
(In reply to comment #15) > yep, i'd agree that an option to use folder art (if present) over embedded art > should be included, for all the reasons said in the last two posts. For clarity, I believe the default actions should be: - *always* use folder.jpg (or whatever) as album art [this is what SC currently does not do] - *always* use embedded art (if present) as track art - if no embedded art, display album art as track art - if no album art, display default image Kind regards
*** Bug 14198 has been marked as a duplicate of this bug. ***
add: bug 2470 bug 4699
I'm now running 7.4 rather than 7.3.3. From my perspective, things have now got worse. The actions in 7.4 appear to be: - take the first image found, and allocate it to the album art - display this image both as album art and when a track is playing. In the case where there is both album art (folder.jpg) and embedded art in each track (in the specific case, an album of hit singles, with each track having its own different embedded art), this results in: - the embedded art from Track 1 is allocated as the album art - browsing by album art shows the art from Track 1 *not* from folder.jpg - when tracks from the album are played, the Track 1 art is displayed for *every* track, even though each track has its own different art Frankly, this makes the SC (sorry, SB Server) artwork display look silly :( At least in 7.3.3 when a track was playing the correct embedded art specific to that track was displayed, even though the album art was incorrect. With 7.4, they are both wrong - except in the single case when Track 1 is playing. Can I suggest again the actions listed in https://bugs-archive.lyrion.org/show_bug.cgi?id=9919#c16
(In reply to comment #19) > I'm now running 7.4 rather than 7.3.3. From my perspective, things have now > got worse. Richard, I think you want to open a new bug for any artwork problems in 7.4. This bug is more of a placeholder for future enhancements. It doesn't appear that any work has been done on this yet, so if you're seeing issues with 7.4 they should be raised separately.
add: bug 4565 bug 5107 bug 5881 bug 11009 bug 11153 bug 11815 bug 12135 bug 12710 bug 12763 bug 14476
sorry, forgot 2: bug 4874 bug 6225
bug 4631
For albums, it's planned to have a one-to-many relationship between an album and images. What's the plan for tracks? Will it be possible to have more than one image per track as well? Given all the optimization going on right now for SbS 7.5 and the embedded server to speed up scanning, it seems to me that having some additional artwork cataloging options would be desirable. I think the option mentioned in comment 1 would be a good start. There's no need to scan every piece of media unless it's desired by the user. Even on fast systems, scans will be quicker for users who find this to be of no benefit. Another artwork option: Track Artwork [x] Use album art for tracks in an album [ ] Permit individual track art The first selection would prevent the scanner from looking for and cataloging embedded artwork for individual tracks, and would give faster scan times. If there are no separate files (cover.jpg, folder.jpg, etc.) that qualify as album art, only then would it look for embedded images. The first embedded image the scanner finds that qualifies as a cover would then be used for both the album and all tracks in the album. The second selection would permit embedded artwork to override the album art for individual tracks, as requested in previous comments above.
I(In reply to comment #24) > For albums, it's planned to have a one-to-many relationship between an album > and images. What's the plan for tracks? Will it be possible to have more than > one image per track as well? > > Given all the optimization going on right now for SbS 7.5 and the embedded > server to speed up scanning, it seems to me that having some additional artwork > cataloging options would be desirable. > > I think the option mentioned in comment 1 would be a good start. There's no > need to scan every piece of media unless it's desired by the user. Even on > fast systems, scans will be quicker for users who find this to be of no > benefit. > > Another artwork option: > > Track Artwork > [x] Use album art for tracks in an album > [ ] Permit individual track art > > The first selection would prevent the scanner from looking for and cataloging > embedded artwork for individual tracks, and would give faster scan times. If > there are no separate files (cover.jpg, folder.jpg, etc.) that qualify as album > art, only then would it look for embedded images. The first embedded image the > scanner finds that qualifies as a cover would then be used for both the album > and all tracks in the album. > > The second selection would permit embedded artwork to override the album art > for individual tracks, as requested in previous comments above. (In reply to comment #24) > For albums, it's planned to have a one-to-many relationship between an album > and images. What's the plan for tracks? Will it be possible to have more than > one image per track as well? > > Given all the optimization going on right now for SbS 7.5 and the embedded > server to speed up scanning, it seems to me that having some additional artwork > cataloging options would be desirable. > > I think the option mentioned in comment 1 would be a good start. There's no > need to scan every piece of media unless it's desired by the user. Even on > fast systems, scans will be quicker for users who find this to be of no > benefit. > > Another artwork option: > > Track Artwork > [x] Use album art for tracks in an album > [ ] Permit individual track art > > The first selection would prevent the scanner from looking for and cataloging > embedded artwork for individual tracks, and would give faster scan times. If > there are no separate files (cover.jpg, folder.jpg, etc.) that qualify as album > art, only then would it look for embedded images. The first embedded image the > scanner finds that qualifies as a cover would then be used for both the album > and all tracks in the album. > > The second selection would permit embedded artwork to override the album art > for individual tracks, as requested in previous comments above. Couldn't agree more - this is how it should work and would be a big feature for me....
(In reply to comment #24) > > The first selection would prevent the scanner from looking for and cataloging > embedded artwork for individual tracks, and would give faster scan times. To reinforce the need for an option to disable the scanning of embedded artwork, see the following forum discussion: http://forums.slimdevices.com/showthread.php?t=79066 Some people have libraries in which they must embed artwork for other applications (such as iTunes), but they also provide separate cover/folder.jpg images. All that scanning and resizing the embedded images does is that it slows down their library scans.
Any plans for 7.6 release of recognizing new or changed artwork when running a new & changed scan?
My number one request for SBS is that embedded artwork from one file never appear as track art for other files. I would like either the default to be...or a user setting that will allow a schema that is as follows: if embedded art is found, use it elseif folder art is found use that else use default SBS art I'm in favor of a user option that would allow folder art to supersede embedded art. I have no objection to an option that would allow embedded art to be used for files with no embedded art. But this needs to not be the default. MOST of the music in my library currently displays incorrect artwork because of the current, illogical default behavior.