I don't see this issue.  Could I trouble you to attach one of your affected files to this bug?  Thanks.

Created attachment 1615 [details]
WMA file with embedded artwork

OK, sorry about the content - it's one of the kids nursery rhyme CD's.

This is a WMA lossless file with embedded artwork that throws up this exception..

Retrieving artwork (thumb) for: file:///C:/Documents%20and%20Settings/Russ/My%20Documents/My%20Music/Dreamland/Dreamland%20Nursery%20Chime%20Medley/01%20Sing%20a%20Song%20of%20Sixpence.wma
readCoverArtTags: Looking for a cover art image in the tags of: [C:\Documents and Settings\Russ\My Documents\My Music\Dreamland\Dreamland Nursery Chime Medley\01 Sing a Song of Sixpence.wma]
ERROR: coverArt: Exception when trying to call readCoverArt() for [file:///C:/Documents%20and%20Settings/Russ/My%20Documents/My%20Music/Dreamland/Dreamland%20Nursery%20Chime%20Medley/01%20Sing%20a%20Song%20of%20Sixpence.wma] : [Can't use string ("� 	") as a HASH ref while "strict refs" in use at C:\Program Files\SlimServer\server/Slim/Formats/WMA.pm line 94.
]

This artwork seems to show up fine in Media player (and media player's Advanced Tag Editor) but also gives me the hash error Luga describes in Slimserver, and displays only the "?" placeholder image.

Changed milestone and severity

using Data::Dump, the $tags include:

 PICTURE                   => MIME::Base64::decode("A6YgCQBpAG0AYQBnAGU....)

thus, looks like the WMA files may now no longer contain a simple 'DATA' value, but instead might be direct mime encoded.
content does appear to have the JFIF header at least.

dropping ->{'DATA'} in both uses makes it work ok. huge image too.

ah, seems the image time time is in the ASFHeaderExtensionObject, instead of the ASFExtendedContentDescriptionObject

so, the fix would be to split out the WM/Picture parsing to it's own function and call it from both ASF parsers.

I should be able to have this working tonight

heh...if they were stored in the packaging, that is.  argh.

Created attachment 1620 [details]
stick header image data into proper place in hash

seems to be very much unpacked in comparison.  just sticking $value into the DATA key does the trick.  the rest of the patch outside the line 741 region is just whitespace stuff.

Well, I took the 05/10 build last night and it still isn't fixd in that version. 
Can you let me know which build this fix will make it into.
cheers
Russ

the nightly isn't expected to fix it.  the patch I submitted isn't necessarily the right fix, so I didn't do anything aside from posting it here.  When you see a notice mentioning the change numbers, that is when it is actually IN a build.

committed to trunk at change 10750 
and to 6.5.1 at change 10751

please reopen if problems still exist

This bug is being closed since it was resolved for a version which is now released!  Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html

If you are still seeing this bug, please re-open it and we will consider it for a future release.

Fresh install of v7.0 r2097 on Linux CentOS 4.6 box, WMA lossless music stored on Terastation accessible via mount point on CentOS box.

Each album has folder.jpg in each directory, in addition to embedded artwork in the WMA files.

scanner.log is full of :

[08-04-25 22:15:42.9223] Slim::Schema::Track::coverArt (299) Error: Exception when trying to call readCoverArt() for [file:///mnt/music/Yello/Stella/01%20Desire.wma] : [Can't use string ("") as a HASH ref while "strict refs" in use at /usr/lib/perl5/vendor_perl/Slim/Formats/WMA.pm line 87.
]

for the first track of every album.  Gallery (and Duet remote) shows only placeholder artwork and not album artwork.

This bug is closed.  Please open a new report and attach a sample file that exhibits the problem.