Bug 11006 - No sound after upgrade; SOX has wrong arguments for Ogg->AIFF
: No sound after upgrade; SOX has wrong arguments for Ogg->AIFF
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Audio
: 7.3.2
: PC Ubuntu Linux
: P1 normal (vote)
: 7.3.3
Assigned To: Alan Young
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-08 02:21 UTC by Harald Alvestrand
Modified: 2009-09-05 14:25 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
Log file (11.36 KB, text/plain)
2009-09-04 19:15 UTC, Fred
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Harald Alvestrand 2009-02-08 02:21:29 UTC
After upgrading from 7.0 to 7.3.2, my squeezeboxes don't make a sound any more.

On investigation, I found that the SOX called by the server refuses to recognize its arguments: from strace:

[pid  6581] execve("/bin/sh", ["sh", "-c", "\"/usr/share/squeezecenter/Bin/i386-linux/sox\" -q -t ogg \"-\" -t raw -r 44100 -c 2 -w -s -x -"], [/* 23 vars */]) = 0
......
[pid  6582] write(2, "/usr/share/squeezecenter/Bin/i386-linux/sox: invalid option -- w\n", 65) = 65

I have not yet found the piece of code that calls the sox binary.
Comment 1 Harald Alvestrand 2009-02-08 02:26:51 UTC
The trace also showed that the squeezeserver spent a bit of time searching for a "lame" program. I do not have lame installed.
Comment 2 Harald Alvestrand 2009-02-08 02:46:21 UTC
according to http://sourceforge.net/forum/forum.php?forum_id=663469 the -w flag was renamed to -2 in sox 13.0.0
Comment 3 James Richardson 2009-02-09 07:27:13 UTC
QA to investigate
Comment 4 Markus Schiegl 2009-02-10 11:09:16 UTC
Harald,

convert.conf is the only place which contains the call from your log.
Does this patch solve your problem?

Index: convert.conf
===================================================================
--- convert.conf	(revision 24947)
+++ convert.conf	(working copy)
@@ -131,7 +131,7 @@
 	-
 
 ogg aif * *
-	[sox] -q -t ogg $FILE$ -t raw -r 44100 -c 2 -w -s $-x$ -
+	[sox] -q -t ogg $FILE$ -t raw -r 44100 -c 2 -2 -s $-x$ -
 
 wma wav * *
 	# F:{PATH=%f}R:{PATH=%F}

SC uses sox 14.2.0

kind regards,
Markus
Comment 5 Harald Alvestrand 2009-02-11 23:26:39 UTC
This patch solved the problem. Thanks!
(had missed /etc/squeezecenter when searching for the squeezebox files).

Thanks for the quick turnaround and effective fix!
Hope you get a "listen to an ogg file" added to the QA procedure!

                Harald
Comment 6 Alan Young 2009-02-12 00:11:37 UTC
Change 24976
Comment 7 Anoop Mehta 2009-04-16 13:45:35 UTC
Verified Fix in SC 7.3.3 r25766
Comment 8 James Richardson 2009-06-17 09:36:54 UTC
This bug has been fixed in the 7.3.3 release version of SqueezeCenter!

If you haven't already. please download the new version from http://www.logitechsqueezebox.com/support/download-squeezecenter.html 

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Comment 9 Fred 2009-09-04 19:15:39 UTC
Created attachment 5789 [details]
Log file
Comment 10 Fred 2009-09-04 19:19:20 UTC
Hi all,

I have switched my SC 7.3.3 setup from windows to QNAP TS239/SSOTS 3.18/SC 7.3.3 (Perl source code). Everything is the same setup except OS. So I have Squeezebox Duet (v3) and an all OGG Vorbis music library. It worked fine on windows. Now, when I try to play a song, I get no sound. But everything else seems to be working properly (leds, browsing my music library, etc). I suspected wrong transcoding config, even though Squeezebox duet (v3) can play ogg files natively. So here is the log when I try to play something:

---

Attached...

---

And here is from netstat while playing it:

---

[/] # netstat
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 localhost:43288 localhost:9092 ESTABLISHED
tcp 0 0 MaisonNAS:3483 192.168.0.197:19984 ESTABLISHED
tcp 0 0 MaisonNAS:9001 192.168.0.196:3894 ESTABLISHED
tcp 0 126 MaisonNAS:13131 192.168.0.196:3844 ESTABLISHED
tcp 0 107521 MaisonNAS:9001 192.168.0.197:19985 ESTABLISHED
tcp 0 0 localhost:9092 localhost:43288 ESTABLISHED
tcp 0 0 MaisonNAS:netbios-ssn 192.168.0.196:2690 ESTABLISHED
tcp 0 0 MaisonNAS:9001 192.168.0.196:3893 ESTABLISHED
netstat: no support for `AF INET6 (tcp)' on this system.
udp 0 0 localhost:37910 localhost:syslog ESTABLISHED
netstat: no support for `AF INET6 (udp)' on this system.
netstat: no support for `AF INET6 (raw)' on this system.
Active UNIX domain sockets (w/o servers)
Proto RefCnt Flags Type State I-Node Path

---

My TS239 is named MaisonNAS. SSOTS and SC are configured on port 9001.

From my windows setup experience, the squeezebox receiver acts like that when it cannot open the file it plays (I once tried to play music when my NAS was shutdown) (or it may be SqueezeCenter letting the receiver think everything is fine). From a thread I read on forums.slimdevices.com, another user had the same problem fixed by opening port 9000 on his firewall (this would be 9001 on my side I guess). Could it be my problem? Do you see something else wrong? To the best of my knowledge, I have no firewall running on my TS239 (it runs Linux kernel 2.6.24). Nothing that I configured myself at least. If it is my problem, since I am new to Linux, could you please tell me how I can check if port 9001 is opened in the firewall and if not, how to open it?

Thanks and cheers,

Fred
Comment 11 Fred 2009-09-04 19:21:41 UTC
Oups, I forgot to mention that I think I have this same bug in 7.3.3, except that it is not wrong arguments... so it might be about reopening this bug...

Alright, thanks!

Fred
Comment 12 Alan Young 2009-09-05 00:24:21 UTC
Fred, I would prefer it if you opened a new bug for this. As you note, SB2s and newer support Ogg natively and therefore no transcoding is involved. This is therefore a different issue.

Your logfile is not quite long enough to see what is happening. player.source=info would be the best level to capture it at. Please can you capture a new logfile at this level with a bit more context (period either side of the failure) and submit this to a new bug report.
Comment 13 Fred 2009-09-05 14:25:08 UTC
Alright. Filed under bug #13878.

Fred