kdf Wrote: > > 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 ! -- catdna ------------------------------------------------------------------------ catdna's Profile: http://forums.slimdevices.com/member.php?userid=377 View this thread: http://forums.slimdevices.com/showthread.php?t=21051 _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
