PDA

View Full Version : Another Artwork Problem ?



catdna
2006-02-12, 17:05
Hi All

I've found an oddity in the Artwork setup of SlimServer :

I noticed that the 'artwork_path' of an album in my database is (correctly) set to the id of the first 'track_id' of the album.

eg. artwork_path : 1662 in the 'albums' database

However, when I try :
http://slimserver:9000/music/1662/cover.jpg

- I get the standard 'no-artwork' cd image.

However, if I try the second track :
http://slimserver:9000/music/1663/cover.jpg

- then the correct album artwork is displayed(!)


Now, if I go through the slimserver interface and navigate to that album, it's displaying the correct album cover art.

What I really want to know is, "how does slimserver now which coverart url to use ?"
I though it was always the first track id for the album (or the 'artwork_path' parameter from the database ?


Or am I missing something here ?


Thanks
Chris

JJZolx
2006-02-12, 19:40
Now, if I go through the slimserver interface and navigate to that album, it's displaying the correct album cover art.

What I really want to know is, "how does slimserver know which coverart url to use ?"
I though it was always the first track id for the album (or the 'artwork_path' parameter from the database ?

Or am I missing something here ?
I recall being confused by this as well. The answer is that SlimServer always "looks" for artwork files when you get to the album view, rather than using the database to get the file location. Dunno why exactly.

DJanGo
2006-02-13, 00:20
Hi All

I've found an oddity in the Artwork setup of SlimServer :

I noticed that the 'artwork_path' of an album in my database is (correctly) set to the id of the first 'track_id' of the album.

eg. artwork_path : 1662 in the 'albums' database

However, when I try :
http://slimserver:9000/music/1662/cover.jpg

- I get the standard 'no-artwork' cd image.

However, if I try the second track :
http://slimserver:9000/music/1663/cover.jpg

- then the correct album artwork is displayed(!)

Hi,

take a look at the first Track, maybe there is something wrong with the tag?

I had the same "Problem" and solved it, by retagging the whole Album.

catdna
2006-02-13, 02:39
I recall being confused by this as well. The answer is that SlimServer always "looks" for artwork files when you get to the album view, rather than using the database to get the file location. Dunno why exactly.


Hmmm.. that sounds a bit... cludgy ?

Can someone from SlimDevices confirm this ?


Hi,

take a look at the first Track, maybe there is something wrong with the tag?

I had the same "Problem" and solved it, by retagging the whole Album.

Nope - all the tracks have been tagged correctly - I've also spotted this behaviour on several other albums too.

Thanks

Chris

kdf
2006-02-13, 03:14
Quoting catdna <catdna.235wdb (AT) no-mx (DOT) forums.slimdevices.com>:

>
> JJZolx Wrote:
>>
>> I recall being confused by this as well. The answer is that SlimServer
>> always "looks" for artwork files when you get to the album view, rather
>> than using the database to get the file location. Dunno why exactly.
>>
>
> Hmmm.. that sounds a bit... cludgy ?

that would be because it was only partly correct. The db is checked,
and will use the info there to grab teh file. If not found, it will
look for artwork and place a found file path into the db.

browse by artwork page is a bit different, since grabbing from the db
so many times can hammer the server a bit too much.those are grabbed
only during scan, and artwork not found in the db is simply given a
blank cover.
-k

catdna
2006-02-13, 06:08
that would be because it was only partly correct. The db is checked,
and will use the info there to grab teh file. If not found, it will
look for artwork and place a found file path into the db.

browse by artwork page is a bit different, since grabbing from the db
so many times can hammer the server a bit too much.those are grabbed
only during scan, and artwork not found in the db is simply given a
blank cover.
-k

But that's my point.

The first track for the album when used in the image url path reutrns the 'blank cover' picture.

eg /music/<track_1_id>/thumb.jpg

All the other tracks for the album used in that url return the correct cover image.

The 'artwork_path' column is set to the id of the first track_id for that album.


However, going through the web interface and browsing through artist / album to view tracks (*not* browsing by coverart) shows the correct album image.

So I can conclude that :

1. The 'album' / 'artwork_path' column for the first track is incorrect (for this problem)

2. SlimServer is pulling the coverart image from somewhere other than the first track ID / track-artwork_path when you navigate to the URL via the web interface.


It's not like I could check if the image returned is incorrect and then use the image from track 2 (as an image is always returned - albeit the 'no cover image'). If I could 'guess' how slimserver is getting the artwork then I could fix this for my plugin.


Really frustrating !