Bug 2774 - Always Hangs When Trying to Play
: Always Hangs When Trying to Play
Status: RESOLVED INVALID
Product: SB 2/3
Classification: Unclassified
Component: Audio
: 28
: PC Windows XP
: P2 normal (vote)
: ---
Assigned To: Blackketter Dean
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-01-01 11:52 UTC by ams
Modified: 2006-01-01 12:37 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description ams 2006-01-01 11:52:21 UTC
Both the 6.2.1 and 6.2.2 versions exhibit this problem...  I would fall back to an older version if I could fine one. :-)  I've tried reinstalling both versions, resetting the sb2, everything I can think of.  I've not been able to get it to work since the 6.2.1 upgrade (and I cannot find the previous release).  If you can point me at some previous versions, I'd be happy to try falling back.

Ok, back to what's happening right now.  I can control the the SB2 from my PC or from the remote.  It works perfectly -- playlists appear, songs are found, genres can be browsed, etc.  I set up some songs to play and the song information appears on the display -- but no audio is generated and the counter never moves.  I can pause and play -- the display updates accordingly -- but still no music or progress on the counter.  I can connect to the slimserver (using http://host:9000/stream.mp3) on my PC via the laptop, and the music streams fine to the laptop.

I am running WinXP with the Windows Firewall disabled, a LinkSys Wireless-G WRT54GS router (and I've tried both firewall enabled and disabled mode) with no MAC filter but I am using WEP encryption.

Player information from the browser:

Player Firmware Version: 28
The IP address for this player is: 192.168.1.106:43581
The ethernet MAC address for this player is: 00:04:20:05:c7:d9
Wireless Signal Strength: 83%

I will happily provide any and/or all debugging information you may wish if you can tell me what to log. :-)  The rest of this ticket has the information from the "Server & Network Health" page.  Note that this is being done while the server is still indexing my music archive after the most recent 6.2.2 upgrade...    I hope it's helpful, because I'm out of ideas at this point.

192.168.1.106

Please queue up several tracks to play on this player and start them playing. Then press the Reset Counters link above to clear the statistics and update this display.
Summary

Control Connection     : OK
Streaming Connection   : OK
Player Signal Strength : OK
Buffer Fullness        : Low
Server Response Time   : OK

Warnings

The playback buffer for this player is occasionally falling lower than ideal. This is a Squeezebox2 and so the buffer fullness is expected to drop at the end of each track. You may see this warning if you are playing lots of short tracks. If you are hearing audio dropouts, please check our network signal strength.
Player Performance : 192.168.1.106

The graphs shown here record the long term trend for each of the player performance measurements below. They display the number and percentage of measurements which fall within each measurement band.

It is imporant to leave the player playing for a while and then assess the graphs.

Player Signal Strength
This graph shows the strength of the wireless signal received by your player. Higher signal strength is better. The player reports signal strength while it is playing.

    < 10 :        0 :  0% 
    < 20 :        0 :  0% 
    < 30 :        0 :  0% 
    < 40 :        0 :  0% 
    < 50 :        0 :  0% 
    < 60 :        0 :  0% 
    < 70 :        0 :  0% 
    < 80 :       18 : 67% #################################
    < 90 :        9 : 33% ################
   < 100 :        0 :  0% 
   >=100 :        0 :  0% 
    max  : 81.000000
    min  : 71.000000
    avg  : 77.444444

Buffer Fullness
This graph shows the fill of the player's buffer. Higher buffer fullness is better. Note the buffer is only filled while the player is playing tracks.

Squeezebox1 uses a small buffer and it is expected to stay full while playing. If this value drops to 0 it will result in audio dropouts. This is likely to be due to network problems.

Squeezebox2 uses a large buffer. This drains to 0 at the end of each track and then refills for the next track. You should only be concerned if the buffer fill is not high for the majority of the time a track is playing.

Playing remote streams can lead to low buffer fill as the player needs to wait for data from the remote server. This is not a cause for concern.

    < 10 :       18 : 67% #################################
    < 20 :        0 :  0% 
    < 30 :        0 :  0% 
    < 40 :        0 :  0% 
    < 50 :        0 :  0% 
    < 60 :        0 :  0% 
    < 70 :        0 :  0% 
    < 80 :        0 :  0% 
    < 90 :        0 :  0% 
   < 100 :        9 : 33% ################
   >=100 :        0 :  0% 
    max  : 99.999968
    min  : 0.000000
    avg  : 33.333323

Control Connection
This graph shows the number of messages queued up to send to the player over the control connection. A measurement is taken every time a new message is sent to the player. Values above 1-2 indicate potential network congestion or that the player has become disconnected.

     < 1 :       23 :100% ##################################################
     < 2 :        0 :  0% 
     < 5 :        0 :  0% 
    < 10 :        0 :  0% 
    < 20 :        0 :  0% 
    >=20 :        0 :  0% 
    max  : 0.000000
    min  : 0.000000
    avg  : 0.000000

Server Performance
The graphs shown here record the long term trend for each of the server performance measurements below. They display the number and percentage of measurements which fall within each measurement band.
Server Response Time
This graph shows the length of time between slimserver responding to requests from any player. It is measured in seconds. Lower numbers are better. If you notice response times of over 1 second this could lead to problems with audio performance.

The cause of long response times could be either other programs running on the server or slimserver processing a complex task.

 < 0.002 :  4455829 :100% #################################################
 < 0.005 :     3147 :  0% 
  < 0.01 :     1099 :  0% 
 < 0.015 :      212 :  0% 
 < 0.025 :      165 :  0% 
  < 0.05 :      337 :  0% 
   < 0.1 :      174 :  0% 
   < 0.5 :      111 :  0% 
     < 1 :       21 :  0% 
     < 5 :       55 :  0% 
     >=5 :        2 :  0% 
    max  : 13.099833
    min  : 0.000083
    avg  : 0.000190

Timer Accuracy
Slimserver uses a timer mechanism to trigger events such as updating the user interface. This graph shows how accurately each timer task is run relative to the time it was intended to be run. It is measured in seconds.

Timer tasks are scheduled by the server to run at some point in the future. As only one timer task can run at once and the server may also be performing other activity, timer tasks always run slightly after the time they are scheduled for. However if timer tasks run significantly after they are scheduled this can become noticable through delay in the user interface.

 < 0.002 :     1862 : 85% ##########################################
 < 0.005 :       23 :  1% 
  < 0.01 :        9 :  0% 
 < 0.015 :       12 :  1% 
 < 0.025 :       23 :  1% 
  < 0.05 :       23 :  1% 
   < 0.1 :       24 :  1% 
   < 0.5 :       67 :  3% #
     < 1 :       55 :  3% #
     < 5 :       75 :  3% #
     >=5 :        6 :  0% 
    max  : 12.807891
    min  : 0.000000
    avg  : 0.109151

Timer Task Duration
This graph shows how long each timer task runs for. It is measured in seconds. If any timer task takes more than 0.5 seconds this is likely to impact the user interface.

 < 0.002 :     1084 : 50% ########################
 < 0.005 :     1016 : 47% #######################
  < 0.01 :       31 :  1% 
 < 0.015 :        1 :  0% 
 < 0.025 :        4 :  0% 
  < 0.05 :       10 :  0% 
   < 0.1 :        0 :  0% 
   < 0.5 :       24 :  1% 
     < 1 :        5 :  0% 
     < 5 :        4 :  0% 
     >=5 :        0 :  0% 
    max  : 1.387458
    min  : 0.000423
    avg  : 0.008658

Scheduled Tasks
The server runs processor intensive tasks (such as scanning your music collection) by breaking them into short pieces which are scheduled when when active players are not requesting data. This graph shows the length of time in seconds that a scheduled task runs for before returning control to the server. Tasks taking over 0.5 second may lead to reduced performance for the user interface.

 < 0.002 :  4459025 :100% #################################################
 < 0.005 :      942 :  0% 
  < 0.01 :      792 :  0% 
 < 0.015 :       85 :  0% 
 < 0.025 :       61 :  0% 
  < 0.05 :      137 :  0% 
   < 0.1 :       36 :  0% 
   < 0.5 :        8 :  0% 
     < 1 :        3 :  0% 
     < 5 :       45 :  0% 
     >=5 :        1 :  0% 
    max  : 13.099685
    min  : 0.000000
    avg  : 0.000080
Comment 1 KDF 2006-01-01 12:03:31 UTC
please contact support@slimdevices.com for help diagnosing the issue.
Comment 2 ams 2006-01-01 12:07:14 UTC
Will do -- my apologies for posting to the wrong forum.
Comment 3 KDF 2006-01-01 12:14:49 UTC
oh, and old versions can be found here:
http://www.slimdevices.com/downloads

and this isn't the wrong forum, but this does (at least on first impression) look like a fault condition that could be sorted out by the support group.  Being able to play music is a fairly major function.  Likely a bug would cause this to happen far more globally.  Support will work through the likely culprits, and if that fails, narrow down the details of any bug causing this. Right tools for the right task after all :) 
Comment 4 ams 2006-01-01 12:24:53 UTC
You are my hero.  Falling back to v6.0.2 fixes the problem.  YAY!  Sad that I can no longer stay in sync with your software updates, but at least it works again.
Comment 5 Blackketter Dean 2006-01-01 12:37:23 UTC
If you do try to upgrade and work out what's going on with support, feel free to create a new bug with details.  thanks.