Hi.
I've been a customer for a while. I have 2 Slimp3s, a SB1, and just
bought a SB2.
The Debian server is a dual proc Xeon with 2 GB RAM running a Tekram
powered SATA RAID 5. I believe machine resources should not be an issue.
It does nothing but serve MP3 files and run Slimserver.
SlimServer Version: 6.2.1 - 5194 - Debian - EN - iso-8859-1
Everything is hardwired.
Things I've tried:
- Resetting the SB2 to factory defaults
- Restarting the server OS
- Restarting SlimServer
- Repeatedly forgetting, then re-adding all the players
Problem #1:
The server plays the same song over & over, never moving on to the next
track. Repeat is off. This is just for this new SB2, not the other
Slimp3s and SB1 connected to the server.
Problem #2:
The SB2 loses connection out every 30-50 seconds, for about 5-25
seconds. Sometimes the buffer is large enough to cover the outage with
no loss of audio, but the time elapsed stops updating, etc.
I do intend to use all players at once, but at the time of testing I'm
just using the new SB2.
I have a continuous ping going on a windows box connected to the same
switch, and I see this:
...
Reply from 10.0.0.211: bytes=32 time<1ms TTL=64
Reply from 10.0.0.211: bytes=32 time<1ms TTL=64
Reply from 10.0.0.211: bytes=32 time<1ms TTL=64
Reply from 10.0.0.211: bytes=32 time<1ms TTL=64
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128 << Outage begins here
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128
Reply from 10.0.0.211: bytes=32 time=1ms TTL=128 << Outage stops here
Reply from 10.0.0.211: bytes=32 time<1ms TTL=64
Reply from 10.0.0.211: bytes=32 time<1ms TTL=64
Reply from 10.0.0.211: bytes=32 time=2ms TTL=64
...
Here's a server network & health dump:
------------------------------------------------------------------------------
Squeezebox2
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 : OK
Server Response Time : OK
Warnings
This player is performing normally.
Player Performance : Squeezebox2
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.
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 : 31 : 3% #
< 20 : 0 : 0%
< 30 : 0 : 0%
< 40 : 1 : 0%
< 50 : 0 : 0%
< 60 : 1 : 0%
< 70 : 70 : 7% ###
< 80 : 6 : 1%
< 90 : 35 : 4% #
< 100 : 837 : 85% ##########################################
>=100 : 0 : 0%
max : 99.999968
min : 0.000000
avg : 92.814475
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 : 170 :100%
##################################################
< 2 : 0 : 0%
< 5 : 0 : 0%
< 10 : 0 : 0%
< 20 : 0 : 0%
>=20 : 0 : 0%
max : 0.000000
min : -1.000000
avg : -0.129412
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 : 20900 : 95% ###############################################
< 0.005 : 668 : 3% #
< 0.01 : 141 : 1%
< 0.015 : 4 : 0%
< 0.025 : 7 : 0%
< 0.05 : 17 : 0%
< 0.1 : 160 : 1%
< 0.5 : 2 : 0%
< 1 : 3 : 0%
< 5 : 1 : 0%
>=5 : 0 : 0%
max : 1.774451
min : 0.000046
avg : 0.001021
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 : 6842 : 99% #################################################
< 0.005 : 10 : 0%
< 0.01 : 3 : 0%
< 0.015 : 8 : 0%
< 0.025 : 10 : 0%
< 0.05 : 16 : 0%
< 0.1 : 9 : 0%
< 0.5 : 11 : 0%
< 1 : 5 : 0%
< 5 : 2 : 0%
>=5 : 0 : 0%
max : 1.461002
min : 0.000000
avg : 0.002572
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 : 6687 : 97% ################################################
< 0.005 : 227 : 3% #
< 0.01 : 1 : 0%
< 0.015 : 0 : 0%
< 0.025 : 0 : 0%
< 0.05 : 1 : 0%
< 0.1 : 0 : 0%
< 0.5 : 0 : 0%
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.043672
min : 0.000042
avg : 0.000553
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 : 0 : 0%
< 0.005 : 10 : 91% #############################################
< 0.01 : 0 : 0%
< 0.015 : 0 : 0%
< 0.025 : 0 : 0%
< 0.05 : 0 : 0%
< 0.1 : 0 : 0%
< 0.5 : 1 : 9% ####
< 1 : 0 : 0%
< 5 : 0 : 0%
>=5 : 0 : 0%
max : 0.273489
min : 0.002292
avg : 0.027011
_______________________________________________
Discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss
