Bugzilla – Bug 6225
Slow cover art loading in playlist
Last modified: 2011-04-28 09:10:47 UTC
The new default skin includes a cover image for each track in the playlist. When adding an album to the playlist, these images slowly load one at a time, even though they are all the same image. Each image has a different URL, and appears to be getting sent over the wire once for each track in the album.
each image is resized and cached by the server. First time is going to be slower, and for some it will appear slower than others due to system resource and network traffic. Any later use should be faster.
Could you please install the latest nightly build an do a full rescan? Images should now be pre-rendered for faster loading.
Sorry, it doesn't feel any faster with r15547. It can take as long as 5 seconds to load the thumbnails when adding an long album to the playlist.
Are you using artwork image files (cover.jpg, folder.jpg, etc.) or artwork embedded as tags? The playlist images can be turned off in the new Default skin. There's a control below the playlist that controls whether artwork is hidden or shown in the playlist window.
Questions to developers: When artwork is embedded, I assume that the resized thumbnails will still be cached, but will they be pre-cached the same as file-based artwork? When artwork is embedded, does that mean each track from an album can have a different file/url for the cached image? If so, it's not hard to see how enabling artwork in the playlist could cause slow load times for albums with many tracks. It might be more prudent to use the artwork pointed at by the _album_, so that all of the images use the same thumbnail and get sent to the browser just once.
This is using artwork stored in cover.jpg. The artwork for each track /always/ has a unique URL, regardless of where it is ultimately fetched from. I imagine what this needs is for artwork to have its own table in the database rather than being a property of a track. Artwork URLs could then be made per-image rather than per-track. There'd then be a bit more processing up-front but fewer round trips between the browser and the server.
(In reply to comment #6) > This is using artwork stored in cover.jpg. > The artwork for each track /always/ has a unique URL, regardless of where it is > ultimately fetched from. Ok, now that I look more closely at it, I see the same thing (using cover.jpg files as well). As you say, this will cause the browser to request each thumbnail separately, as though each were a unique image. The URLs aren't actual paths in the web server, so it's apparently a function of how SC's image caching operates. This is probably the first time the problem has been exposed, since in the past you'd seldom have more than one instance of an image on a page.
Might be related to bug 6471? Peter - what are your machines' (client/server) specs?
The client is an Athlon 2800 and the server is a 1500MHz VIA Esther. Both have 1GB of RAM and are running Fedora. The new default skin feels generally quite slugish with this setup.
Peter: How slow is it? Given that the files are unique per song, they are going to load separately, but once created and cached they should be reasonably fast.
It takes about 5 to 6 seconds to load all of the thumbnails for a 12 song album when they're not in the browser cache. The first doesn't appear to be any slower than the others. Note that I'm not taking any detailed timings, here, just using a wristwatch. Come to think of it, I think the real problem doesn't come when adding an album at all. When you open the web page, the existing playlist is often loaded in its entirety before the navigation pane on the left hand side displays. If you're opening the page to create a new playlist, this is time that is entirely wasted.
Alan is able to reproduce, he'll be attaching a log.
Well I have found some problems with (non-)caching of images that are taken from track tags. See bug 6769. There is indeed a general issue with the model of each track in an album being able to have its own image. But the question remains as to why performance seems to be so variable across platforms and browsers. I continue to investigate.
The perceived performance seems to be influenced by many factors: browser+plugins, client platform and server platform (both hardware and OS). I have found no additional factors which dominate this equation. The per-track/track-indexed model for (album-)art clearly does not help but any changes here are beyond the scope of what is reasonable for SC 7.0. Pushing off to 7.0.1 but quite possibly this will have to wait for 7.1.
Would it be such a disaster if SqueezeCenter did NOT go out of its way to support individual artwork images per track? I mean, isn't the whole idea of artwork supposed to be ALBUM artwork? What if track-artwork were displayed in no other place than the song info page? This might greatly simplify the display of artwork in both the playlist and now playing panes. It's only when you get into embedded artwork that it's possible to have different images per track. But even with embedded track artwork wouldn't you reasonably expect that a _very_ high percentage of users will have the same artwork image for individual tracks as they would for the whole album?
I agree. It is just that this is too big a change for 7.0.1
I have been unable to get any useful info to add to the diagnosis of this issue. Un-targetting and marking unassigned for further review.
This is probably fixed in 7.6.
Is this fixed? I am assuming this is so. Please change bug status if not true.
yes, the artwork loads quickly now when adding tracks to a playlist in the web control (In reply to comment #19) > Is this fixed? I am assuming this is so. Please change bug status if not true.