Bugzilla – Bug 4371
After power outage - Slim::Player::Source::errorOpening Squeezebox2.pm line 569
Last modified: 2008-12-18 11:41:57 UTC
I listed this under "Hardware", but I don't know if this is accurate ... read on. I experienced a power outage in my apartment while I was at work. My squeezebox 3 (I'll abbreviate as SQ3) was powered off (but connected to a surge-protecting power strip), and configured for my wireless (WEP) 802.11g network. When I returned home, there was power to my SQ3 when I turned it on from the remote, but the equipment in my home-office on a separate circuit, with wireless router, Linux-based slimserver, etc. was off. After restoring power in my office and booting up my slimserver, my SQ3 (already powered on in my living room) was able to connect to my wireless network and my slimserver, and display my favourites. Using the remote, I selected my "BBC World Service" internet radio listing and my SQ3 started downloading a URL of the form "mms://...." (e.g. mms://a1149.l1305038288.c13050.g.lm.akamaistream.net/D/1149/13050/v0001/reflector:38288 ). However, it gave up shortly thereafter with a "Connection Timed Out" error. I checked everything -- firewall, wireless, etc. -- and I confirmed that I can connect to that same URL and listen to that station via my laptop. This confirmed that external network connectivity through my firewall was fine. I verified via a web browser that my SQ3 was connected to my slimserver. Also looking at the SQ3 itself, my WeatherDateTime power-off screen saver worked fine. I got this in /tmp/slimserver.log every time I tried to play the above station (also tried Radio France International): 2006-10-13 19:48:44.4986 Backtrace: frame 0: Slim::Player::Source::errorOpening (/usr/local/slimserver/Slim/Player/Squeezebox2.pm line 569) frame 1: Slim::Player::Squeezebox2::failedDirectStream (/usr/local/slimserver/Slim/Networking/Slimproto.pm line 526) frame 2: Slim::Networking::Slimproto::_disco_handler (/usr/local/slimserver/Slim/Networking/Slimproto.pm line 387) frame 3: Slim::Networking::Slimproto::client_readable (/usr/local/slimserver/Slim/Networking/Select.pm line 238) frame 4: Slim::Networking::Select::select (/usr/local/slimserver/slimserver.pl line 487) frame 5: main::idle (/usr/local/slimserver/slimserver.pl line 440) frame 6: main::main (/usr/local/slimserver/slimserver.pl line 1039) This suggested a software problem. I tried restarting the slimserver, rebooting my Linux box to check for filesystem corruption, deleting everything under .../Cache/FileCache, etc. but no luck. I tried connecting to Squeezenetwork and that timed out as well. Finally, I unplugged my SQ3 and plugged it back in and voila ... it works fine. So ... this seems a little fragile to me ... it's working now, but I thought I should report it in case there's something that can be done to make the whole setup more robust. Is there some kind of bug that might cause these symptoms? Is there some protocol magic that happens at power up that doesn't happen later? Other info: - SlimServer_v6.5.0.noarch.rpm - Mandrake 9.1 - perl 5.8.0 (yeah, yeah, I know ... )
there should be more to the error in the log before the backtrace. Given that it's a radio url, I suspect that when power came on, that the SB3 may not have gotten a proper DHCP setup, and may not have had a working direct internet connection in order to establish a direct stream. As this isn't something that can be sipmly reproduced, I can only hypothesize. Probably something that should have gone through support@slimdevices.com, as this isn't really something that can qualify as a bug yet. Some sort of cause needs to be found in order to eliminate several other variable.s
RE: DHCP .. per my comments, the fact that my squeezebox could connect over my wireless network and I could see it connected from my slimserver browser interface (I verified that it had a valid IP), and that the WeatherDateTime plugin (which downloads current weather conditions) suggest that the network connectivity between my slimserver and squeezebox was fine (as well as Internet connectivity from slimserver). RE: logs ... unfortunately, there was nothing relevant in the logs before the backtrace. There were some "Charset #33" errors related to mysqld from the startup (which seems to be a known issue + harmless), but nothing else preceding the backtrace. If it happens again I'll contact support ... Are there some recommended debug settings that might help collect better data in the future?
for internet radio, best debug settings to start with would be d_http_async and d_direct_stream. the former handles the request, and the latter is the resulting handover to SB2 for direct stream playback. adding d_source may also help to provide the output that is currently missing prior to the backtrace.
Will do. Thanks for your prompt responses!
Did you ever find anything more about this, VK? I have been unable to reproduce it here.
No ... it has not happened again, and I haven't had time to try and reproduce it. I did turn on some of the debug flags you mentioned, and that should provide additional data for you if it happens again.
Okay. I will just let it hang around as an open bug for now. You might ask on the forums to see if anyone else has seen this issue, and if they could add their info to the bug. All info is handy to help me try to reproduce bugs! Thanks!
Please reopen if this is reproducible.
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html