Preferred album artwork

[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?

[d6jg]

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]

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]

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]

- 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?

- 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]

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]

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.

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.

- 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!

- 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]

Maybe someone can update this with the results of the analysis/discussion
http://wiki.slimdevices.com/index.ph...abaseStructure
and
http://wiki.slimdevices.com/index.php/Album_Artwork

[Roland0]

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:

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.

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:

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]

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

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.

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.