Caching of embedded album art

[dinfinity]

The caching mechanism doesn't seem to process embedded album art. I have a few albums in which the mp3s contain relatively very large (~640kb) embedded album art.

Whenever a song of one of these albums is played, the player only responds to 'next' or other commands after it is done loading and resizing the embedded image (which sometimes takes several seconds).

I could, of course, reduce the sizes of the embedded images, but I'm lazy :-)

Also, perhaps a more compelling reason: it seems more efficient to use the (effective) caching mechanism for embedded album art instead of using cpu cycles for resizing the image every time a song with embedded art is played.

[admin]

Thanks for the report. Caching works only for downloaded album art, embed album art is always extracted. Though, 640kb album art shouldn't take more than 100ms to decode (which is slow of course, but this is phone, not pc). PowerAMP uses special algorithm which ensures the decoded image won't be larger thant 1000x1000px (even if it's originally larger than that), so the top time should be constant. "Several seconds" is somewhat unusual. It can be something with the image format as well.

PowerAMP album art resolver/downloader is currently runs in the separate thread and album art download requests are serialized, though, it won't affect the playback functionality - this runs in isolated specific threads independently of other parts.

Please send that (one) track to poweramp.maxmpz gmail.com for some tests. PowerAMP v2.0 now processes multiple album art images (up to 5) in advance and I want to be sure that all types of embed art is processed fast.

Also, what is your phone model/Android os version?

[dinfinity]

Phone is (Dutch) HTC Desire Z (Virtuous 1.0.1 Custom ROM (Android 2.2.1) (and many more customizations).

Side note: the tracks (with large embedded album art) do start playing, it's just that most controls are dysfunctional while the image is decoded.

Sample track will be emailed asap!