Bugzilla – Bug 10651
Boom audio stops working after trying to play Internet audio sources
Last modified: 2009-04-06 07:25:44 UTC
Hi Slim, I am the (otherwise) satisfied owner of 2 Duets and 2 Booms. My 2 Booms share a problem. The Duets do NOT have this problem. Neither do the SqueezePlay Beta, I downloaded when SC 7.3.1 was released. Problem/Bug description: 1) First, I ensure that the Boom can play music from my music library on my SC server. 2) Open an Internet Radio station (details below) from the favorites menu. Or a podcast. 3) Boom says: connecting, fills buffer (counts up to 100%) and playing - the usual sequence. It happens pretty quickly, but I think it goes through all the usual steps. 4) NO SOUND! 5) The spectrum meter, I have as display background, does not show any activity. If I chose a radio station while playing an album, the spectrum meter freezes on the “last well-formed music sample” – Even when the Boom is turned off and on. 6) I can still navigate all menus and if I choose to play an album from the music library, there is still no sound. Also the next and previous buttons won’t work: album “playing” is stuck on the first track. 7) There is no way that I can get any sound from the Boom after this, unless I disconnect/reconnect power. And before I do that, I need to select an album from the music library; otherwise the Boom just goes directly into bad state again. The above behavior applies to all Internet audio sources. These are the ones I have tried (all Danish): a) WMA Internet radio, 128 Kbps CBR: http://www.dr.dk/netradio/Metafiler/asx/dr_boogie_128.asx b) MP3 Internet radio, 128 Kbps CBR: http://onair.100fmlive.dk/100fm_live.mp3.m3u c) Podcast, mp3: http://podcast.dr.dk/P1/HARDDISKEN/2009/HD_090107.mp3 from the feed: http://podcast.dr.dk/p1/rssfeed/harddisken.xml. d) Various RadioIO station selected via SqueezeNetwork, e.g. “Slim showcase Miles Davis”. e) Apparently the login to SqueezeNetwork works ok… I don’t know what to conclude from that… Technical details: * SqueezeCenter 7.3.1 running on a Fujitsu Siemens Homeserver, which runs Windows Homeserver, which is based on Windows 2003 Server. All updates applied. * Boom is running on firmware 41. * Home PCs are running Vista and music library is in FLAC format. This bug did also reveal the fact that the alarm clock was silent when the Boom was in bad state. It would be very much appreciated, if the alarm clock was able to at least make some other noise in this situation. I was late for work one day due to this :o( I hope you can help me out. Thanks. Best regards, Morten Schmidt Kagerup Stationsvej 15 DK-3200 Helsinge Denmark Email: morten@alur.dk
I have a couple of additional comments: - Booms connected to a wireless network, G-standard, but I haven't given that much thought, since SC music plays just fine. - Booms and Duets share an ADSL Internet connection through a Netgear WGR614 wireless router, but likewise I haven't given that much thought, since Internet audio plays just fine through the Duets. - I have tried connecting the Booms through a cable, but that didn't improve things. Br Morten
QA Confirmed, the listed play intermittently, on Boom connected to SC 7.3.2 r24586. they do play properly on Transporter every time. See attached logs
Created attachment 4618 [details] Server Log Streams played OK on BOOM, after playing to a Transporter
Created attachment 4619 [details] Server Log Look to the END of the log, the streams failed to start on the boom, then did once I tried them on the Transporter
Do you want me to gather a log file for you? (How do I do that?)
James to try wiping the caches and trying again. Alan notes this could be a duplicate of a bug titled something like 'streams fail to play first time' bug 9471
I took a look at the suggested duplicate bug 9471. Maybe it is related, but apart from that, mine is very different. For example the fact, that there is absolutely no way of getting any sound from the Boom, once it's in bad state. At least I haven't found any way of getting it in good state again without a cold start. I have looked at the log files. I have a 2.1 GB "server.log.0" with lots of these errors: [08-12-15 18:56:11.1793] Slim::Networking::IO::Select::select (271) Error: Select task failed: Can't call method "nextChunk" on an undefined value at /<C:\Program Files\SqueezeCenter\server\squeezecenter.exe>Slim/Web/HTTP.pm line 2123. If I exclude these errors (using MS LogParser 2.2), the log is down to 558 KB. Judged on the date, these errors must originate from version 7.3. I now run 7.3.1. There are no messages in the log file from today, even though I just provoked the error once again. Is there any way to get the Boom to log its errors "internally", and then get to them afterward? Br Morten Schmidt
(In reply to comment #7) > There are no messages in the log file from today, even though I just provoked > the error once again. > > Is there any way to get the Boom to log its errors "internally", and then get > to them afterward? > Mort: In SC go to Settings > Advanced > logging Place a check mark in 'save logging settings...' Turn the following to DEBUG player.source player.streaming player.streaming.direct Shut down SqueezeCenter Rename or delete the messages file(s) Start SC Re-Produce the error Shut down SC Attach the new messages log to this bug.
Created attachment 4631 [details] SC log file with debugging of bad state James: I did what you wrote. Log file attached: "server -- error provoked.log". Sequence: 1) Played flac track from SC (Grandjean - Island...) 2) Tried Internet radio: http://www.dr.dk/netradio/Metafiler/asx/dr_p1_128.asx 3) Player now in bad state. 4) Tried step 1 again - no sound. I also checked debug for "player.streaming.remote" - it sounded relevant. Br Morten
In your log, did the WMA radio station play OK? It appears to have played fine, and plays fine here.
No: from the second i open (any) Internet radio, the audio is gone. In step 2+3+4 above the audio is gone. And don't come back! Also applies to trying MP3 radio and MP3 podcasts as described above.
Also please note, that both my 2 Booms show this behavior. Both are at firmware version 41. Both my Duets behave well.
I have looked at the log and cannot see what is happening. I offer this analysis in case it helps. 1. The local track plays fine. 2. The WMA radio station starts up well enough. The scan works fine, then direct streaming is initiated, the headers are parsed and buffering starts and, after about a second, passes the threshold mark. But the track simply does not start (no track-started notification is received). 3. Try to play the local track again. First stop is sent (I can't see anything that would get in the way of sending strm-q), then the new stream is started. SC gets the streaming headers back from the player (so it is clearly reacting to the strm-s) but, again, it never starts playing the track. Weird.
I can't reproduce. Please try the latest 7.3.2 nightly build.
I have now downloaded and installed the latest nightly build: 7.3.2-24630. Note: the installation warns me about port 9000 being in use (it is), even though I have set my server.pref to 9010. Well, SC works fine anyway - on port 9010. 7.3.2-24630 did NOT solve anything for me :o( The problem is still unsolved. Any more ideas? Can we get the Boom to be more verbose about things? Can this be debugged or logged on the Boom side of things, now that SC doesn't tell us much?
Testing this out I discovered that if I got a 'failing' boom, and waited about 1 minute, audio would start from one of the failing streams. I was only able to get (c) the pod cast to fail today, both A & B played just fine for me. Morten: Have you tried SqueezeNetwork yet? Are you able to get your booms to fail with the same Internet streams on SqueezeNetwork as well? There is no 'boom side' logging -- Please verify your Firewall settings as well, did you modify Exceptions > SqueezeCenter tcp (UI) to reflect the change in server port from 9000 > 9010 Can you check your server 2003 event logs to see if anything strange or unusual is listed there?
One other question, what do you have that is using port 9000? why did you have to change SC from 9000 to 9010
Response to James: * Waiting one minute: nothing happened :o( * SqueezeNetwork: I retested just to make sure. I checked this originally - points d) and e) in my original bug report. * Windows Firewall (on server): that was already ok. * Windows EventLogs: I just provoked the error once more. Silence in all logs! * Port 9000 was occupied on the home server by TwonkyMedia server, which was preinstalled. I shut it down and changed SC from port 9010 to 9000 and added port 9000 to Exceptions in Windows Firewall: no luck. Until this is solved, I will let my SC use port 9000. Other experiments: I replaced the Netgear wireless accesspoint with a Linksys WRT54GR which I replaced some months ago with the Netgear because ruined my Duet synchronization too often. The WRT54GR did not better things. Changed back again. Checked the Netgear for firmware update - it was up to date. Changed wireless encryption from WEP to WPA2 AES (which I should have done ages ago anyway). No changes wrt this bug. Ok, I wasn't expecting to solve the problem by messing with my wireless network - I just had to try. I also tested with cable earlier on. --- Tomorrow a colleague at work will take one of my Booms home and test it on his own network. He has both a Boom and a SB3 that doesn't have this problem. Hopefully we can them rule out my specific version of the Boom hardware. --- Maybe I could install a protocol analyzer on the server (like Wireshark). I have used those at work for http traffic analysis. But this is lower level, and I wouldn't know what to look for. Maybe not a good idea... --- To me, it looks like the only thing left is, if Slim could produce Boom firmware for me that could trace this situation. It also bugs me, why the Duets and the SqueezePlay don't have this problem, I mean: same network, same server, same audio streams. The only thing different is the Boom hardware.
Morten: 1 last thing to try on your boom before your friend takes it, a factory reset. Press and hold the left arrow button on the front of boom till you get to the setup menu. Scroll up to Current Settings - press the knob Scroll up to Factory Reset - press the knob after the boom reboots, follow the setup procedure to attach to your network re-test to verify if the issue is still happening.
James: factory reset didn't help. We will see how it behaves when on my colleagues network. Will be back this. Thanks for all your help. I really hope that we can get this sorted out. I like the little things.
James: wrt to feeding the Boom over cable: should I make sure that the wireless network is disabled to make sure that this test works correctly? Should I do a factory reset first, for the test to be focused?
I just did the following: factory reset the Boom, chose Ethernet connection, pointed to SC on my server and repeated my test. Problem is still there. I think that this effective rules out the wireless part of the equation. It has something to do with the Boom's packet handling or the code that starts playing of the Internet data stream. The buffering seems to work OK, but the Boom could actually store the buffered data in a wrong way so that when the buffering phase is done, the buffered data is actually corrupt in some way. I will get back to you when my colleague have tested. Now I will go to work - a bit late today.
Hmm, this is a very strange bug indeed. I've tested a), b), c) and d). They all play fine here. I added them to my favorites and either started them from SCs web interface or via presets on Boom. Same difference, they play fine. - SC 7.3.2 on SuSE Linux 10.2 - Boom firmware 41 (wireless) As an additional test I played a FLAC song from my library first (as mentioned in comment #9) then switched to one of the four again and they also play fine after a FLAC song.
My colleague borrowed my first Boom and got it to play Internet radio straight from his SqueezeNetwork account. Boom got firmware 41. After that he connected it to his SqueezeCenter 7.2.1 (firmware 33) where it also played everything. Conclusion on this: its not the hardware. --- At home, I couldn't make my second Boom play any Internet radio. My colleague took over the second Boom remotely via the Internet by entering it's PIN in his SqueezeNetwork account. It got firmware 41 and played Internet radio for the very first time! I took it back by entering it's new PIN in my own SqueezeNetwork account. Now it plays Internet radio from my own SqueezeNetwork account! Since then I have tried SqueezeCenter versions 7.2.1 after a complete uninstall (except for prefs), 7.3.2-24630 and right now 7.3.1 (which has firmware 41 in it just like the SqueezeNetwork). I can now consistently make it play Internet radio via SqueezeNetwork and not via my own SqueezeCenter. After each failed attempt via SqueezeCenter, I have to pull power before it will play Internet radio via SqueezeNetwork. --- I will get my first Boom back tomorrow - I wonder if it behaves well, when it gets home!?!?!?
I have uploaded my server.prefs for you to look at - maybe you can try it out? (First I blanked out sn_email, sn_password_sha and an_session.)
Created attachment 4656 [details] Morten's server.prefs
I GOT IT FIXED! I got my first Boom back, but it behaved just my second one at home. I then uninstalled everything and accepted deletion of prefs and everything. I then installed 7.3.1 from scratch, which solved everything. That was a big moment! For the first time I can use my new Booms without problems. What a blessing! I have spent some time looking in the server.prefs files, but frankly I think it requires an insider to interpret the differences. I will upload my working file shortly, so you have both before (failing) and after (ok) versions. I have looked a little though - out of curiosity - my diff tool shows that almost every single is different between the two, so it takes some work to read through the files. A couple of interesting settings are different between the old file and the new one: - maxWMArate: 9999 (only in old) - mp3StreamingMethod: 0 (only in old) - _ts_maxWMArate: -1 (0 in new) ---------------------- Could you share some thoughts on this? Do you think that the server.prefs settings was the problem?
Created attachment 4668 [details] New and well functioning server.prefs
I would also like to add that I think that this was a serious bug. One should not be able to cause malfunction by just adjusting settings via the menues. The only thing that I have changed in server.prefs file was the port number - and nothing else.