Bugzilla – Bug 5941
Cover art not shown for all tracks in current playlist
Last modified: 2007-11-08 10:23:28 UTC
Cover art seems to be missing for some tracks in the current playlist. I'm not sure if this is a skin problem or a scanner problem. I don't have any cover art images in the MP3 tags, instead I have a cover.jpg in the albums directory. All the tracks are stored in the same folder. The cover art is missing from some of the tracks on the album beside the track in the current playlist, however when I select the track so it is displayed in the left frame the cover art is shown correctly for the same track. I'll attach some database dumps and screenshots.
Created attachment 2322 [details] Screenshot with the problem As you can see the cover art of track 7 is missing in the current playlist, however, when I've clicked on it and displayed it on the left frame you can also see that the cover art is displayed correctly there.
I was going to also attach some database dumps, becuase the cover column in the tracks table was null for the tracks that didn't show the cover art. However, suddenly they've got a value. I think it got a value when I clicked on the track without cover art to display the song details. It then seems to have filled the cover column in the tracks table for both track 7 and track 10. If I now refresh the browse the cover art is there correctly. So this makes me think that it might be something wrong in the scanning process that causes this. I cleared the Artwork cache and performed a full rescan again and this seems to happen: 1. During the scanning only the first track on the album get a value in the cover column in the tracks table 2. When I add the artist the current playlist it strangely enough shown the album arts for all albums, but this is probably due to the web browser cache. 3. When I hit the refresh button in the browser it fills the cover column in the tracks table for all the other tracks besides the first. So this second time all cover arts for this artist was really shown correctly. But I'm very sure that this didn't happend the first time and also some times before. But the question that remains is. If the cover column in the tracks table needs to be filled for the artwork in the Default skin current playlist to work, shouldn't this be handled by the scanning process ?
Hm I'm surprised I haven't heard of or seen this. We'll try to reproduce it here.
Erland, see the comments in bug 6073 and see if the latest SC7 revision fixes this problem for you. Change 14469 should also fix your bug 5943 and a few related bugs where adding items to the playlist sometimes causes a foreign key constraint violation. To answer the question about artwork. I believe the way it works is that the path to the album cover is stored in one track (usually track number 1), then the album record gets the track id of that track. All the other tracks on the album generally have NULL in the cover column and resolution of the cover is through membership in the album, leading back to the file path stored in track 1. There's also a convention used when the artwork is embedded in the music file itself - I think maybe it just stores the the full path to the music file again in the cover column.
(In reply to comment #4) > Erland, see the comments in bug 6073 and see if the latest SC7 revision fixes > this problem for you. Change 14469 should also fix your bug 5943 and a few > related bugs where adding items to the playlist sometimes causes a foreign key > constraint violation. I've tried to reproduce this with the latest svn, and it seems to work so I'll mark this as fixed. I'll reopen it if the problem appears again.