View Full Version : Unable to scan/play WMA files

2009-11-04, 17:47
There seem to be a number of us with QNAPs who are unable to either scan or play WMA files since upgrading to the latest SSOTS and SC 7.4.x I don't have my exact logs to hand but this post from the following thread is exactly my issue


"...On all WMA files get I get the following error written in the Server log when SBS scans my collection; "Invalid ASF header".
In the scanner log it says "Unable to read tags from file" on all WMA-files.
Worked flawlessly on 7.3.3 on SSOTS 3.18..."

SSOTS 4.1-7.4.0
SBS 7.4.1-28947

2009-11-04, 18:04
On Nov 4, 2009, at 7:47 PM, nicktf wrote:

> "...On all WMA files get I get the following error written in the
> Server log when SBS scans my collection; "Invalid ASF header".
> In the scanner log it says "Unable to read tags from file" on all
> WMA-files.

This sounds like a bug in Audio::Scan, but I can't reproduce on any of
my ARM systems: a SheevaPlug, SB Touch, or a QEMU ARM VM, all of which
pass all the WMA tests just fine.

2009-11-05, 00:31
This sort of bug sounds very similar to one which is preventing BBCiPlayer from working on QNAP. The BBCiPlayer bug looks like a problem when unpacking a header where the values returned are not in the expected range.


I wonder if the bug is in either SSOTS or the support libraries.

2009-11-07, 00:24
+1 for not playing wma files

2009-11-07, 00:52
EDit: I was too hasty - problem is not solved yet but it is related to QNAP beign ARM little endian

The problem with BBCiPlayer on QNAP only systems turns out to be a bug in the perl that is bundled with SSOTS. So the proper solution may be to get flipflip to update the perl build assuming there is a fix for the bug.

See post #39 and earlier.

The BBCiPlayer bug is associated with QNAP being little endian (unlike the other ARM systems) and it manifested itself when data packing into the Flash protocol header was incorrect. A number of fields which should be integers appear as 5.29980882362664e-315 after packing.

2009-11-07, 06:27
Hope they can sort this bug out in the end

2009-11-07, 06:44
bpa are you sure that's it? All my ARM systems are little-endian, and the WMA code also passes tests on a big-endian system such as the Sparc ReadyNAS.

2009-11-07, 07:35
I am not 100% sure as I don't have a QNAP system to play with but on the BBCiPlayer bug all the symptoms point to an endian issue possibly due to a problem with the perl supplied with SSOTS.

In the BBCiPlayer problem, the number 5.29980882362664e-315 appears where a small integer is expected. A few years ago this same number appeared in an ARM port of a Tiff library for perl and AFAICT the solution involved doing a swap words in the double.

ARM specifications state that data values accessed in word format are invariant with respect to endianness. If a program stores a 32-bit value at a given memory address, then switches the endian configuration of the processor and reads back the 32-bit value at that same address, it will get the correct result. However, if data are read or written in smaller chunks (8 or 16 bits), this will no longer hold true.

This mean ARM is a mixed endian which I think means that a double will always have the same word order regardless of BE or LE but the byte order within the words will depend on BE/LE.

Now given that this behaviour is low level I would expect that Perl/C would normally hide this from the user. So as I see it there are two possibilities
* serialisation of data for protocols where words are used sometimes and bytes at othertimes during formatting/decoding data via pointers might be causing the problem.
* SSOTS perl has been built with some special option settings -- a perl -V would help

2009-11-08, 12:05
Was beginning to think I was the only one with a problem.

I've been looking at fixing this for a week or so and have just got some time to look at it. I've noticed that Audio::Scan has never managed to pass it's unit tests on my Synology DiskStation. Have filed a bug and patch (Bug 15074).

The source fix is simple - if you've a SSODS ELDK build environment to hand. You need to alter one file in the Audio::Scan distribution - Change this line in include/common.h:



And rebuild the package and install it into /opt/ssods4/lib/perl5/site_perl/5.10.0/armv5tejl-linux-thread-multi/auto/Audio/Scan/

If you don't have this to you want to try out a built one from a complete unknown (I know i wouldn't :-) ) I've attached built versions of 0.44 (to replace the current SSODS) and 0.48 (the current one required for 7.4.2)

2009-11-09, 07:54
For the record - the QNAP ARM is a mixed endian system unlike Touch.

See this post for my test results. http://forums.slimdevices.com/showpost.php?p=483393&postcount=52

I don't know if this is the WMA problem but it does indicate that any code running QNAP has to be careful with word order especially when dealing with 64 bit numbers.

2009-11-09, 10:47
I've released Audio::Scan 0.49 that should fix this issue.

2009-11-09, 13:31
Hi Andy. I am running a qnap ts 109 with those issue. I see you have a solution but I am not how to implement it. Can you point me in the direction for how to do this at all please?

2009-11-10, 05:22
I've released Audio::Scan 0.49 that should fix this issue.


I also have the problem regarding wma files.
I am not experienced with updating sections of the software on the QNAP.
Can someone tell me where to get and how to install the new scan module on my ts109II.



2009-11-11, 14:42
Hi Andy - likewise, I have the same pesky wma scan problem and would love to implement a fix. Any help gratefully received!

SSOTS 4.1-7.4.0

2009-11-11, 14:44
You need to obtain a newer version of SSOTS, I'm not sure how you go about that...

2009-11-13, 09:50
I've released Audio::Scan 0.49 that should fix this issue.

How do I install this to SSOTS on my QNAP?

Also, should I use 0.50 or 0.49?

2009-11-18, 16:35
I have squeeze server 7.4.1.
I downloaded audio-scan 0.44-......
Unzipped this file
Stopped Squeezeserver in SSOTS

To place this file in /opt/ssods4/lib/perl5/site_perl/5.10.0/armv5tejl-linux-thread-multi/auto/Audio/Scan/ I used FileZilla (is a free FTP program)

I did make a connection with server using "SFTP SSH file transfer protocol"

Followed the path from the root /opt/ssods4/lib/perl5/site_perl/5.10.0/armv5tejl-linux-thread-multi/auto/Audio/Scan/
Renamed the file Scan.so into Scanold.so
placed the file Audio-Scan-0.44-SSODS-armv5tej.so in this map
Renamed this file in Scan.so
Started up squeezeserver again with SSOTS
And did a complete new scan.

2009-11-20, 16:09
Having followed Cees' instructions, I'm now rescanning my music and SSOTS' scan log shows that all is going well with my wmas (no error messages this time). I will leave it running overnight and see what's waiting for me in the morning....

Thanks to all!

SSOTS 4.1-7.4.0
SBS 7.4.1

2009-11-21, 08:34
Yipee! All my WMAs are back - thanks!


2009-11-21, 08:59
I downloaded audio-scan 0.44-......


so again a question... where can I find the download?
Is really scan 0.44 or is it 0.49?


2009-11-23, 13:24
Well, 0.44 (downloaded using the link in Parky's post (#9 in this thread)) worked for me - I installed it exactly as above without any probs. I'm running SBS 7.4.1 and SSOTS 4.1-7.4.0 (the latter downloaded from FlipFlip's SSODS/SSOTS site (I couldn't get the QPKG link to work))


2009-11-24, 11:57

I downloaded the scan file (0.44) and installed it as indicated and ...
all files are scanned now.

Many thanx


2009-11-26, 13:40
Hi guys

I'm running SC 7.4.1 on SLES 10 Sp2 and have the same problem with scanning my wma files.
It seems that the posted fix is only for SC running on NAS devices.
Am I missing something?
Thanks for your help in adv.

2010-02-04, 01:25
Hi I was just wondering if anybody has tried upgrading to ssots 4.4 to fix the wma audio:scan problem? I've been having the same trouble with 4.1 7.4.1 not recognising wma files. Thanks in advance - Nick

Just to say its finally working now and I had to go back to 4.1 and replaced the file scan.so to get it playing normally again - Thanks for everyone's help.