snarlydwarf Wrote:
Yeah, just last week Sony sent me a PS3 because my PS2 is being phased
out. And Nissan sent me a new car, because the 2005 model is just,
well, dated.
It is very normal to have an upgrade path for software. It often costs
a substantial sum, though, but it is usually
dapnyc Wrote:
Did you ever buy a stereo component that suddenly stopped working with
CD's? Did you ever buy a car that, after you took it to the shop to
tune it up, suddenly didn't function with gas? My point is that they
upgraded the software without telling customers that it would render
One thing that hasn't been discussed (if I've seen it right): FLAC isn't
supported natively in SB1. It therefore has to be transcoded to WAV
(double the bandwidth) or MP3 (poorer quality). I guess the first is the
case. And wireless can't keep up with the bandwith needed. If you limit to
More tuning has happend to 6.5 than 6.3, so I would hope 6.5 will be
able to support SB1s well once it is stable.
If you find a problem on 6.5 please enable the following and report
what you see in the server log:
1) go to Server Network Health
2) enable performance monitoring
3) go to Server
Folks, I'm not a techie by any stretch, so I hate to intrude in the
debate, but as a s1 owner I came to this board for the same reason as
all of you: I'm trying to figure out if there is a simple fix for the
S1 constantly hesitating when playing music with the most recent
releases of the server.
Yeah, just last week Sony sent me a PS3 because my PS2 is being phased
out. And Nissan sent me a new car, because the 2005 model is just,
well, dated.
It is very normal to have an upgrade path for software. It often costs
a substantial sum, though, but it is usually around.
How many personal
Christopher Key wrote:
The log seems to suggest that XML::Parser and YAML::Syck are either built
correctly (or alternatively that they are not being built at all, and are
hence being loaded sucessfully from the system CPAN path), but that most of
the rest of the modules are failing. I've just
Pat Farrell wrote:
Christopher Key wrote:
Could you try ./slimserver.pl --d_startup
I've reformatted the content below to make it a little more readable
(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17
./slimserver.pl --d_startup
Got @INC containing:
Triode Wrote:
Looks like scrobbler could be improved, but the internal server
functions are better. Hopefully the web page one can be improved
further with the new database code which is comming.
This should not have happended - did anyone else see it?
If it helps I'll try to repeat
Since I've been having this problem as well, Triode suggested I try
the 6.5 build. rather than the current 6.2.xxx
I had a 6.5 working a while back, but the current nightly on 6.5
does not execute. I installed via RPM onto my Mandriva 2006 system
and it is whining about perl modules not being
Have you run the build script (./Bin/build-perl-modules.pl) to make the
new modules needed?
This is needed as Mandravia 2006 has chosen to build perl without
multithread support so the architecture of the precompiled modules in
the rpm is different from that needed for your perl.
--
Triode
Triode wrote:
Have you run the build script (./Bin/build-perl-modules.pl) to make the
new modules needed?
No, I just did the rpm and tried to run it.
DIdn't know voodoo was needed.
This is needed as Mandravia 2006 has chosen to build perl without
multithread support so the architecture of
Triode wrote:
Have you run the build script (./Bin/build-perl-modules.pl) to make the
new modules needed?
Now I have, and I'm not sure it is happy.
This seems to require root.
Warning: prerequisite AppConfig 1.55 not found.
Building..
Library for Template-Toolkit-2.14.tar.gz is OK!
then I get
Thanks interesting - your perl architecture is
i386-linux-thread-multi. My Mandravia 2006 is i386-linux, but it is
a never version of perl.
In this case I would have thought it should run the rpm as is without
the extra modules. Try removing everything in the CPAN directory and
re installing
Triode wrote:
What does it say when you try to start the server manually with
./slimserver.pl?
That's what I did in the last message
./slimserver.pl
Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains:
Pat Farrell wrote:
Triode wrote:
What does it say when you try to start the server manually with
./slimserver.pl?
That's what I did in the last message
./slimserver.pl
Could you try ./slimserver.pl --d_startup
___
beta mailing list
Christopher Key wrote:
Could you try ./slimserver.pl --d_startup
(beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17
./slimserver.pl --d_startup
Got @INC containing:
/home/pfarrell/incoming/SlimServer_v2006-05-17
/usr/lib/perl5/5.8.5/i386-linux-thread-multi
/usr/lib/perl5/5.8.5
Looks like scrobbler could be improved, but the internal server
functions are better. Hopefully the web page one can be improved
further with the new database code which is comming.
hickinbottoms Wrote:
(by the way, I had to delete my old prefs as the server kept complaining
they were
Triode Wrote:
This should not have happended - did anyone else see it?
Mine upgraded fine on windows, Thanks for all the improvements.
Craig
--
Craig
Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
Triode Wrote:
Stuart - if you try the latest 6.5 (today's nightly), you should find
the writePrefs delay is much reduced. Do you see this?
Just picked up this message - I'll give that a try tonight and report
back to this thread. Thanks for the pointer to the update.
--
hickinbottoms
Triode Wrote:
Stuart - if you try the latest 6.5 (today's nightly), you should find
the writePrefs delay is much reduced. Do you see this?
I've rerun a similar type of test with r7430 (I'd backed out the patch
to HTTP.pm so it was unmodified from the Subversion version).
As before the
Right I've just switched on perfwarn, not sure which other debug flags I
should be setting though???
This looks bad, is it?
2006-05-09 09:32:55.1774 Slim::Utils::Prefs::writePrefs
2006-05-09 09:32:55.1782 Response Time 0.5 : 0.738317012786865
2006-05-09 09:35:25.2366 Start and End node:
Triode Wrote:
Stuart - could you post the whole log (ziped?) Or just a few lines above
each of these.
Reason for asking is that we need the lines above the Response Time
0.5 lines...
Good news is that we should be able to reduce the ones due to
writePrefs quite easily...
I've
I make the dominant freezes:
writePrefs - 1.3 sec - seen often
Notify: Slim::Player::Playlist::modifyPlaylistCallback
+ Scrobbler and SuperDateTime plugin related
+ web page related ones which this doesn't give enough info for
I think we need to work on these two first (as I see them too). The
Triode Wrote:
Are you willing to try 6.5 as I am about to put some more diagnostics
in this to help understand what causes long response times.
I can give it a go on windows if you tell me what to do.
Craig
--
Craig
I've just installed the 5/8 build of 6.5 windows and I seem to be able
to do anything with the web browser with only small dips in buffer
fullness as opposed to the pauses I was getting before :-)
I'm still getting pauses when Random Mix makes a new selection but I've
tracked this to DBI:Find
Dan Sully Wrote:
FYI - here's a better patch which checks the size of the sndbuf first.
Doesn't seem to have improved matters here, I'm still getting dropouts
caused by the server process hogging CPU. This is with 6.5b1 build
7296, and a library of 6000-ish songs.
Which debug flags
Do those dropouts only occur during a rescan? Try setting the new
perfwarn option. You'll need the latest nightly for this.
./slimserver.pl --perfwarn=0.5
--
andyg
andyg's Profile:
andyg Wrote:
Do those dropouts only occur during a rescan? Try setting the new
perfwarn option. You'll need the latest nightly for this.
./slimserver.pl --perfwarn=0.5
OK ta - will grab it now and try. And no, they occur when the web
interface has a lot to do - e.g. Browse Artists.
andyg wrote:
Do those dropouts only occur during a rescan? Try setting the new
perfwarn option. You'll need the latest nightly for this.
Not for me, they occur during normal playback.
Or, they also occur during normal playback. During rescan,
my server is unlistenable. Its only a AMD2400+ or
OK, right. Those heavy database pages are still a problem I'm not sure
we'll be able to solve until we get DBIx::Class merged in from
split-scanner.
--
andyg
andyg's Profile:
ron thigpen wrote:
Craig wrote:
I'm still getting pauses when Random Mix makes a new selection but I've
tracked this to DBI:Find and I guess this will be covered by the move to
mySQL?.
This glitch is also apparent on my SB2s. It really messes up any
attempt to use Random Mix with two
Robin Bowes Wrote:
ron thigpen wrote:
Craig wrote:
I'm still getting pauses when Random Mix makes a new selection but
I've
tracked this to DBI:Find and I guess this will be covered by the
move to
mySQL?.
This glitch is also apparent on my SB2s. It really messes up any
I can view any page except view artwork without pausing on a 10,500 song
DB so that's a definate improvement.
Pat - apart from the rescanning, aren't your problems caused by other
apps using the cpu? whereas these fix's seem to be related to
SlimServer stalling the streaming.
Craig
--
Craig
kdf wrote:
this has been covered before. feel free to search, to avoid going
through the same exact discussion again :)
___ beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta
I've had a bit of a dig, but
I've had a bit of a dig, but not found anything that seems to be conclusive.
Could you point me in the right direction, as you know what you're looking
for.
http://forums.slimdevices.com/showthread.php?t=15613
http://forums.slimdevices.com/showthread.php?t=1166
To add the the post from Andy above - I would be interested in the
output from the --perfwarn option added to last night's 6.5 from anyone
having problems streaming to SB1. This may help target the problem
areas in the current server architecture.
Start the server from the command line with the
Triode,
The main ones I'm seeing are
2006-05-08 20:29:20.4101 Request Task 0.5 : 8.02541708946228
2006-05-08 20:29:20.4106 Notify:
Plugins::RandomPlay::Plugin::commandCallback
2006-05-08 20:29:20.4118 Response Time 0.5 : 8.05730199813843
Which Dan said has been dealt with in the split
Thanks - for info:
Craig Wrote:
2006-05-08 20:29:20.4101 Request Task 0.5 : 8.02541708946228
2006-05-08 20:29:20.4106 Notify:
Plugins::RandomPlay::Plugin::commandCallback
2006-05-08 20:29:20.4118 Response Time 0.5 : 8.05730199813843
This one is a problem and as Dan says should be
2006-05-08 20:32:19.7901 Slim::Web::HTTP::processHTTP
2006-05-08 20:32:23.1430 Select Task 0.5 : 4.31901407241821
This one is not actually a problem as the Response Time has not
exceeded the threshold. It means the task is doing some tricks to
stream audio while it is running, i.e. the
kdf wrote:
I've had a bit of a dig, but not found anything that seems to be
conclusive. Could you point me in the right direction, as you know
what you're looking for.
http://forums.slimdevices.com/showthread.php?t=15613
http://forums.slimdevices.com/showthread.php?t=1166
Triode Wrote:
To add the the post from Andy above - I would be interested in the
output from the --perfwarn option added to last night's 6.5 from anyone
having problems streaming to SB1. This may help target the problem
areas in the current server architecture.
To add my data to this I've
MOMENTARY PAUSES while SlimScrobbler is submitting (just this once
- it
didn't happen for any of the other track submits)
2006-05-08 19:45:16.2600 Timer Task 0.5 : 1.34793710708618
2006-05-08 19:45:16.2616 Plugins::SlimScrobbler::Plugin::submitter
2006-05-08 19:45:16.2631 Response Time
Stuart - could you post the whole log (ziped?) Or just a few lines above
each of these.
Reason for asking is that we need the lines above the Response Time
0.5 lines...
Good news is that we should be able to reduce the ones due to
writePrefs quite easily...
--
Triode
Craig wrote:
Pat - apart from the rescanning, aren't your problems caused by other
apps using the cpu? whereas these fix's seem to be related to
SlimServer stalling the streaming.
It could, of course, be anything. But the box is dedicated to being a
SlimServer. It doesn't even have a monitor
You could try increasing it to MAXCHUNKSIZE * 3. [don't think the
kernel will support it going much bigger though]
I'm assuming you are streaming as raw pcm. In this case (32K * 3) is
about 0.5 seconds of additional buffering. Hence it should aborb small
server delays. What we need to do is
Pat Farrell wrote:
Triode wrote:
you may want to try the following small edit:
setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;
Let me listen a bit and I'll let you know.
So far, I've listened to four or five CDs end to end,
and not noticed any dropouts. A small sample,
I'm seeing this too, gaps in the music drive me mad when using the web
interface for anything. I can see slimserver.pl using 99% CPU on my
linux server when this happens.
Jon.
--
jonmyatt
jonmyatt's Profile:
On May 5, 2006, at 9:37 AM, jonmyatt wrote:
I'm seeing this too, gaps in the music drive me mad when using the web
interface for anything. I can see slimserver.pl using 99% CPU on my
linux server when this happens.
Processing TT templates can take some time, especially if they are
On May 5, 2006, at 9:59 AM, Andy Grundman wrote:
On May 5, 2006, at 9:37 AM, jonmyatt wrote:
I'm seeing this too, gaps in the music drive me mad when using the
web
interface for anything. I can see slimserver.pl using 99% CPU on my
linux server when this happens.
Processing TT
Thanks Andy,
I'm looking forward to the move to mySQL but wouldn't it make more
sense to make the streaming more resilient rather than trying to fix
everything that could stop it?
Craig
--
Craig
Craig's Profile:
On May 5, 2006, at 10:32 AM, Craig wrote:
Thanks Andy,
I'm looking forward to the move to mySQL but wouldn't it make more
sense to make the streaming more resilient rather than trying to fix
everything that could stop it?
Yeah, audio data should be the top priority. I was just throwing
Andy Grundman wrote:
On May 5, 2006, at 10:32 AM, Craig wrote:
Thanks Andy,
I'm looking forward to the move to mySQL but wouldn't it make more
sense to make the streaming more resilient rather than trying to fix
everything that could stop it?
Yeah, audio data should be the top
andyg Wrote:
Yeah, audio data should be the top priority. I was just throwing out
some ideas. :)
That's ok, I didn't understand half of what you said anyway :)
I Just thought I'd bring it up because as 6.5 develops I can see it
happening more and more and I guess that SB1's will be in
Hmm, I'm already using MySQL - didn't seem to fix it for me.
--
jonmyatt
jonmyatt's Profile: http://forums.slimdevices.com/member.php?userid=4124
View this thread: http://forums.slimdevices.com/showthread.php?t=23641
cjk32 Wrote:
It would be nice to be able to run the thread serving audio data with a
high priority, the web interface at normal, and the scanner at low
priority.
It'd certainly be of use to people like me who don't run slimserver on
a dedicated server.
I'm not even sure that's necessary. I
Stuart,
Just as an aside, I can't download the lazysearch zips from the trac
site, they show as corrupt!
Craig
--
Craig
Craig's Profile: http://forums.slimdevices.com/member.php?userid=96
View this thread:
Craig Wrote:
Just as an aside, I can't download the lazysearch zips from the trac
site, they show as corrupt!
Oh dear, that's not right. They work for me when I've just tried it
(opening the archive with either WinZip or 7-Zip on Windows, downloaded
with Firefox).
Can you try the following
hickinbottoms Wrote:
I'd therefore also prefer the streaming to be split off rather than the
scanning - after all most of the performance problems reported are
because audio stutters during scanning, not that the web interface is
sluggish.
Hmmm, at the risk of sounding churlish, for me it's
On May 5, 2006, at 11:53 AM, jonmyatt wrote:
hickinbottoms Wrote:
I'd therefore also prefer the streaming to be split off rather
than the
scanning - after all most of the performance problems reported are
because audio stutters during scanning, not that the web interface is
sluggish.
On May 5, 2006, at 12:12 PM, Andy Grundman wrote:
On May 5, 2006, at 11:53 AM, jonmyatt wrote:
hickinbottoms Wrote:
I'd therefore also prefer the streaming to be split off rather
than the
scanning - after all most of the performance problems reported are
because audio stutters during
andyg Wrote:
I assume you guys are using 6.5 nightlies or trunk? I just committed
a patch that implements idleStreams during template processing. I'm
testing on an SB1 streaming FLAC and can reload the main web
interface repeatedly without any dropouts. Please test on your
You should also be able to see the performance improvement from this on
the Server Response Time graph in the Health plugin.
This should also give an indication if the server is taking a long time
to spin back to select which is causing SB1 dropouts. I'd be interested
to see what is says in
hickinbottoms wrote:
cjk32 Wrote:
It would be nice to be able to run the thread serving audio data with
a high priority, the web interface at normal, and the scanner at low
priority. It'd certainly be of use to people like me who don't run
slimserver on a dedicated server.
I'm not even
this has been covered before. feel free to search, to avoid going
through the same exact discussion again :)
___
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/beta
While we're on this, but considering the current architecture - I was
wondering whether we really want idleStreams to handle all sockets on
the select vectors. This increases the chance of handling a new web
page in the middle of processing another. Would a reduced set for
idleStreams be
andyg Wrote:
I assume you guys are using 6.5 nightlies or trunk? I just committed
a patch that implements idleStreams during template processing. I'm
testing on an SB1 streaming FLAC and can reload the main web
interface repeatedly without any dropouts. Please test on your
pfarrell Wrote:
Craig wrote:
I'm seeing more and more problems with pausing on SB1's using flac
and
6.5
I have been seeing dropouts on my SB1 (wired) ever since I started
using the 6.x series servers.
I am sure that I entered an issue into bugzilla on it long ago,
but I just
Pat,
Given then I know you are on linux, you may want to try the following
small edit:
In Slim/Web/HTTP.pm
Find the line:
# setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;
and replace with:
setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;
This won't
Well, I also suffered from dropouts with my SB1 wired and SlimServer
running on a really slim server (VIA EPIA 5000 @ 533MHz, 2 250GB
external USB 1.1 drives).
The solution I found at that time (and which I still use) was to run 2
simultaneous SlimServers on different ports, one for the music
Triode wrote:
Given then I know you are on linux,
You bet.
Linux beatles.pfarrell.com 2.6.8.1-12mdk #1 Fri Oct 1 12:53:41 CEST 2004
i686 AMD Athlon(tm) 3000+ unknown GNU/Linux
you may want to try the following small edit:
setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE
* Triode shaped the electrons to say...
Find the line:
# setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE;
and replace with:
setsockopt $httpClient, SOL_SOCKET, SO_SNDBUF, MAXCHUNKSIZE * 2;
This won't make the server go any faster, but does seem to make use of
a
* Dan Sully shaped the electrons to say...
FYI - here's a better patch which checks the size of the sndbuf first.
Oops. Let's try that again.
-D
--
iNoah you know, most free operating systems come preinstalled with their own
high horse.
=== Slim/Web/HTTP.pm
73 matches
Mail list logo
