Bug 7444 - Wrong cover displayed for album with cover.jpg and different track images
: Wrong cover displayed for album with cover.jpg and different track images
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Artwork
: 7.4.0
: Macintosh Other
: P4 minor with 1 vote (vote)
: 7.8.0
Assigned To: Michael Herger
:
Depends on: 9919
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-07 11:08 UTC by Andy Grundman
Modified: 2014-08-06 11:56 UTC (History)
4 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andy Grundman 2008-03-07 11:08:56 UTC
Test case - NIN - Ghosts.  Currently the album cover image is just one of the track images (track 16 in my case).

Each track has individual artwork and there is a cover.jpg file.  Album cover should prefer cover.jpg if present, otherwise use the cover from track 1.
Comment 1 KDF 2008-03-07 12:46:49 UTC
This will get complicated. During a scan, artwork is populated by album so that we get all of the thumnail images.  SC looks for ID3 then filenames for each track in the album until something can be stored in the album cover.

During BMF, we process individual files, populating that file's album->artwork if art is found and the album currently shows as not having artwork.  

During scan, it's simple enough to overwrite any ID3-found artwork when a file is found, but when we find artwork during BMF or hasChanged (triggered on a mtime change) then we don't know where the artwork originally came from. What if track 1 disappeared?  should you replace?  What if another track is changed, do we assume the new artwork overrides or just keep the old art?  If so, how will we know if the art that has changed, isn't intended to change the album?  Perhaps we only update album art on BMF or hasChanged if the cover.jpg is NOT found.  If cover.jpg is there, we'd have caught it in the scan.  If we are checking track artwork and find a cover.jpg, then override the album image?

At this point, it's probably worth making a decision tree.  Artwork is far more complicated than the original design intent.


Comment 2 Hanno Stock 2008-05-03 09:29:50 UTC
I am very much for a user selectable option that allows files take precedence over ID3. For example I only store small thumbs in the files for my portable player.
Now Squeezecenter only uses these thumbs. I'd be ok if this option only worked on a full rescan.
Comment 3 ivo 2008-09-25 09:46:03 UTC
I have some suggestions for modifying the way artwork is handled.
Please see http://forums.slimdevices.com/showpost.php?p=340738&postcount=1

I think that there should be some "decision tree"  of handling multiple artwork per album/track that the community should chime in.

NIN's last two albums are good examples of having different track and album artworks.  But any other album would at least have the different cover/back/CD, etc.

I do not know how MP3 handle artwork but FLAC has specifications for different artwork. At the moment "track" is not one of the options.  Maybe TYPE "2: Other file icon" can be used for that.

Per metaflac --help:
--import-picture-from=FILENAME|SPECIFICATION  Import a picture and store it in a                      PICTURE block.  

TYPE is optional; it is a number from one of:
   0: Other
   1: 32x32 pixels 'file icon' (PNG only)
   2: Other file icon
   3: Cover (front)
   4: Cover (back)
   5: Leaflet page
   6: Media (e.g. label side of CD)
   7: Lead artist/lead performer/soloist
   8: Artist/performer
   9: Conductor
  10: Band/Orchestra
  11: Composer
  12: Lyricist/text writer
  13: Recording Location
  14: During recording
  15: During performance
  16: Movie/video screen capture
  17: A bright coloured fish
  18: Illustration
  19: Band/artist logotype
  20: Publisher/Studio logotype
  The default is 3 (front cover).  There may only be one picture each of type 1 and 2 in a file.

I would also like to be able to see other artwork displayed in SC when at Album level.
Comment 4 Andy Grundman 2009-07-29 14:58:35 UTC
Moving 7.4 bugs to 8.0.
Comment 5 Michael Herger 2014-08-06 11:56:43 UTC
This is fixed in 7.8.x