Preferred album artwork

**d6jg** · 2020-07-05, 16:57

Originally posted by wickedlemon

Just started using LMS and so far enjoying it. Previously I've just been streaming from Poweramp on my phone.

One thing I'm struggling with is album artwork and the way LMS prioritises different art. I probably have an atypical setup where I keep album artwork stored in the file as folder.jpg. I then embed artwork into files (such as single covers, original album art on compilations). My problem is that LMS prefers to use the embedded art from the first track instead of folder.jpg if both are present. Weirdly, if track 1 doesn't have embedded art it works fine and displays folder.jpg in album view but overrides with the embedded art in track view elsewhere.

Is there anyway to change the priority order for album artwork to make files preferred to embedded?

Not that I am aware of.
It is as you say embedded, then folder.jpg
Because LMS will handle FLAC etc many people opt for zero embedded art and a high quality upto 1000x1000 folder.jpg and use tools to make low res MP3 versions with embedded art for car use etc

**wickedlemon** · 2020-07-19, 19:50

I've had a closer look and the database doesn't seem very well designed for this. Cover art is stored in tracks and albums are linked to the track with the cover art. Not the way I'd design a database...

I've managed to get some way to what I want by modding the scanner code so it only adds album art if it's a file. This works except when every track on an album has embedded art. For the odd exception I've just added a short blank extra track.

**Roland0** · 2020-07-20, 01:54

Originally posted by wickedlemon

I've had a closer look and the database doesn't seem very well designed for this. Cover art is stored in tracks and albums are linked to the track with the cover art. Not the way I'd design a database...

While I also would like to be able to prioritize external files, you comment above seems to make two questionable assumptions:
- Tracks with cover art always belong to an album (not necessarily true, e.g. missing album tags)
- All tracks from the same album have the same artwork (not necessarily true, I have albums where each track has it's own artwork)

**wickedlemon** · 2020-07-20, 08:41

Originally posted by Roland0

- Tracks with cover art always belong to an album (not necessarily true, e.g. missing album tags)

That's poor library management on the user's part, surely?

Originally posted by Roland0

- All tracks from the same album have the same artwork (not necessarily true, I have albums where each track has it's own artwork)

Not at all. Each track can have a unique artwork and each album points to one TRACK for the artwork to represent it. To assume the above you have either misread something or I wasn't making myself clear (probably the latter).

**Roland0** · 2020-07-20, 17:02

Originally posted by wickedlemon

That's poor library management on the user's part, surely?

In a perfect world...

Not at all. Each track can have a unique artwork and each album points to one TRACK for the artwork to represent it. To assume the above you have either misread something or I wasn't making myself clear (probably the latter).

Currently, all artwork is stored in the artwork DB. Artwork is referenced both from tracks and albums independently.
Your approach seems to offer not benefit compared to that, and the following drawbacks:
- not possible to have independent artwork for an album representing it in e.g. an overview (master->detail)
- added complexity to handle cases where the track representing the album is deleted or assigned to different album
- inefficient access to album artwork (album->track->artwork)

**wickedlemon** · 2020-07-20, 18:48

Originally posted by Roland0

Currently, all artwork is stored in the artwork DB.

My artwork.db contains a cache table with 227 rows. I have approx 2000 albums with artwork plus tens of thousands of embedded images. Can you elaborate on how LMS links albums in the library.db to the artwork.db please? I'm genuinely interested.

Originally posted by Roland0

Artwork is referenced both from tracks and albums independently.
Your approach seems to offer not benefit compared to that, and the following drawbacks:
- not possible to have independent artwork for an album representing it in e.g. an overview (master->detail)

The LMS scanner prevents this. It's impossible to allocate artwork to an album that isn't allocated to a track first. Don't blame me - that's the way the scanner code appears to work.

Originally posted by Roland0

- added complexity to handle cases where the track representing the album is deleted or assigned to different album

If a track is deleted the scanner rescans the tracks and finds another image that is also linked to a track. You just can't have independent album artwork. If you could it would solve my problems!

Originally posted by Roland0

- inefficient access to album artwork (album->track->artwork)

Again, can you explain how albums reference the artwork database please, because it's not obvious looking at the database tables?

**Paul Webster** · 2020-07-20, 19:17

Maybe someone can update this with the results of the analysis/discussion

SlimServerDatabaseStructure - SqueezeboxWiki

http://wiki.slimdevices.com/index.php/SlimServerDatabaseStructure

and

Album Artwork - SqueezeboxWiki

http://wiki.slimdevices.com/index.php/Album_Artwork

**Roland0** · 2020-07-21, 03:21

Originally posted by wickedlemon

Can you elaborate on how LMS links albums in the library.db to the artwork.db please? I'm genuinely interested.

library.db: coverid in tracks, artwork in albums
artwork.db: k
where:

Code:

sub _key { 
	my $md5 = Digest::MD5::md5_hex($key);                                    	                                                                                                                    
        return hex( substr($md5, 0, 8) ) . hex( substr($md5, 8, 7) );
}

Note that LMS currently only stores cached artwork in this DB.

Originally posted by wickedlemon

The LMS scanner prevents this. It's impossible to allocate artwork to an album that isn't allocated to a track first. Don't blame me - that's the way the scanner code appears to work.
If a track is deleted the scanner rescans the tracks and finds another image that is also linked to a track. You just can't have independent album artwork. If you could it would solve my problems!

I am talking about the database design, which I thought was clear as this was the comment I replied to:

Originally posted by wickedlemon

I've had a closer look and the database doesn't seem very well designed for this. Cover art is stored in tracks and albums are linked to the track with the cover art. Not the way I'd design a database...

You are now talking about the application, which isn't the same thing.

**wickedlemon** · 2020-07-23, 20:00

Originally posted by Roland0

library.db: coverid in tracks, artwork in albums
artwork.db: k
where:

Code:

sub _key { 
	my $md5 = Digest::MD5::md5_hex($key);                                    	                                                                                                                    
        return hex( substr($md5, 0, 8) ) . hex( substr($md5, 8, 7) );
}

Note that LMS currently only stores cached artwork in this DB.

That contradicts what you wrote previously.

Originally posted by Roland0

I am talking about the database design, which I thought was clear as this was the comment I replied to:

You are now talking about the application, which isn't the same thing.

Really? You're splitting hairs now. The database is part of the application. They are pretty useless without each other and specifically designed to work as one item.

I have LMS album view working how I need it with my abominable alterations so I see no point in discussing this further. I've moved on to "fixing" other things to work how I need them for my own personal installation.

Preferred album artwork

Preferred album artwork

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment