Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 320kbps it will be transcoded to MP3 and might fix your issues. -- Michael --- Help translate SlimServer by using the StringEditor Plugin (http://www.herger.net/slim/) ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 update slimserver.pl slightly so that it'll report where the modules are being loaded from regardless of whether some modules fail to load, so it would be interesting to run slimserver.pl --d_startup again. I can't really comment of build-perl-modules.pl, so would suggest that until someone better qualified can comment, that you try installing DBD::SQLite and Compress::Zlib (and optionally, GD and Locale::Hebrew). I had to manually upgrade my CPAN version, and then hand installed DBD::SQLite Compress::Zlib Locale::Hebrew and CGI::Util So far, it is at least starting, and scanning my library. Running 6.5b1 - 7390 - Linux - EN - iso-8859-1 which is a couple of days old. So far, it is too soon to tell about the struggling SB1 -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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: /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl . Extended @INC to contain: /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th read-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th read-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre ad-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre ad-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-m ulti /home/pfarrell/incoming/SlimServer_v2006-05-17/lib /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl . Removing [Time::HiRes] from the symbol table - load failed. Removing [DBD::SQLite] from the symbol table - load failed. Removing [DBI] from the symbol table - load failed. Removing [DBI] from the symbol table - load failed. Loaded module: [XML::Parser] ok! Removing [HTML::Parser] from the symbol table - load failed. Removing [HTML::Entities] from the symbol table - load failed. Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains: /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th read-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-th read-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre ad-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thre ad-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-m ulti /home/pfarrell/incoming/SlimServer_v2006-05-17/lib /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/5.8.5/AutoLoader.pm line 160. at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm line 15 Removing [Compress::Zlib] from the symbol table - load failed. Removing [Digest::base] from the symbol table - load failed. Removing [Digest::SHA1] from the symbol table - load failed. Loaded module: [YAML::Syck] ok! Removing [GD::Polygon] from the symbol table - load failed. Removing [GD::Image] from the symbol table - load failed. Removing [GD] from the symbol table - load failed. Removing [Locale::Hebrew] from the symbol table - load failed. The following modules failed to load on the first attempt: [Time::HiRes, DBD::SQLite, DBI, HTML::Parser, Compress::Zlib, Digest::SHA1] - will try again. The following optional modules failed to load on the first attempt: [GD, Locale::Hebrew] - will try again Loaded module: [Time::HiRes] ok! Loaded module: [DBI] ok! Loaded module: [HTML::Parser] ok! Loaded module: [Digest::SHA1] ok! The following optional modules failed to load: [GD, Locale::Hebrew] after their second try. The following modules failed to load: DBD::SQLite Compress::Zlib To download and compile them, please run:
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 available. Usually RPMs just work. Is this a known problem of the 6.5 RPM or something wacky about my system or ...??? Thanks Pat -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 the precompiled modules in the rpm is different from that needed for your perl. I can try this later today Pat -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 All done! Then I attempt to run it and get Changelog2.html Changelog5.html convert.conf Graphics IR Plugins slimserver.pl types.conf (beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17 ./slimserver.pl Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains: /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/lib /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/5.8.5/AutoLoader.pm line 160. at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm line 15 The following modules failed to load: DBD::SQLite Compress::Zlib To download and compile them, please run: /home/pfarrell/incoming/SlimServer_v2006-05-17/Bin/build-perl-modules.pl -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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: /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/lib /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/5.8.5/AutoLoader.pm line 160. at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm line 15 The following modules failed to load: DBD::SQLite Compress::Zlib To download and compile them, please run: /home/pfarrell/incoming/SlimServer_v2006-05-17/Bin/build-perl-modules.pl -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl . Extended @INC to contain: /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/lib /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl . Removing [Time::HiRes] from the symbol table - load failed. Removing [DBD::SQLite] from the symbol table - load failed. Removing [DBI] from the symbol table - load failed. Removing [DBI] from the symbol table - load failed. Loaded module: [XML::Parser] ok! Removing [HTML::Parser] from the symbol table - load failed. Removing [HTML::Entities] from the symbol table - load failed. Can't locate auto/Compress/Zlib/autosplit.ix in @INC (@INC contains: /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8.5/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/5.8/i386-linux-thread-multi/auto /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/arch/i386-linux-thread-multi /home/pfarrell/incoming/SlimServer_v2006-05-17/lib /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN /home/pfarrell/incoming/SlimServer_v2006-05-17 /usr/lib/perl5/5.8.5/i386-linux-thread-multi /usr/lib/perl5/5.8.5 /usr/lib/perl5/site_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/site_perl/5.8.5 /usr/lib/perl5/site_perl /usr/lib/perl5/vendor_perl/5.8.5/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.5 /usr/lib/perl5/vendor_perl/5.8.4/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.4 /usr/lib/perl5/vendor_perl/5.8.3/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.3 /usr/lib/perl5/vendor_perl/5.8.1/i386-linux-thread-multi /usr/lib/perl5/vendor_perl/5.8.1 /usr/lib/perl5/vendor_perl .) at /usr/lib/perl5/5.8.5/AutoLoader.pm line 160. at /home/pfarrell/incoming/SlimServer_v2006-05-17/CPAN/Compress/Zlib.pm line 15 Removing [Compress::Zlib] from the symbol table - load failed. Removing [Digest::base] from the symbol table - load failed. Removing [Digest::SHA1] from the symbol table - load failed. Loaded module: [YAML::Syck] ok! Removing [GD::Polygon] from the symbol table - load failed. Removing [GD::Image] from the symbol table - load failed. Removing [GD] from the symbol table - load failed. Removing [Locale::Hebrew] from the symbol table - load failed. The following modules failed to load on the first attempt: [Time::HiRes, DBD::SQLite, DBI, HTML::Parser, Compress::Zlib, Digest::SHA1] - will try again. The following optional modules failed to load on the first attempt: [GD, Locale::Hebrew] - will try again Loaded module: [Time::HiRes] ok! Loaded module: [DBI] ok! Loaded module: [HTML::Parser] ok! Loaded module: [Digest::SHA1] ok! The following optional modules failed to load: [GD, Locale::Hebrew] after their second try. The following modules failed to load: DBD::SQLite Compress::Zlib To download and compile them, please run: /home/pfarrell/incoming/SlimServer_v2006-05-17/Bin/build-perl-modules.pl Exiting.. (beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17 (beatles)root#/home/pfarrell/incoming/SlimServer_v2006-05-17 -- Pat
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 so with a gig of ram -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 not found anything that seems to be conclusive. Could you point me in the right direction, as you know what you're looking for. Chris ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 http://forums.slimdevices.com/showthread.php?t=21984 http://forums.slimdevices.com/showthread.php?t=14453 http://forums.slimdevices.com/showthread.php?t=1348 and some of these refer to other threads that I haven't bothered to dig up. If I've missed anything, I'm sure those involved would be more than happy to reiterate or contradict their previous statements. -kdf ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 task runs for longer than the threshold, but the response time does not. Right. There are 2 reasons processHTTP could take a long time: 1. Long time to render templates. This situation is handled by calling idleStreams during each template's processing phase so should not cause problems. 2. Long database queries (Browse Albums, etc). This cannot currently be worked around and will cause dropouts. Once we get to split- scanner if we still have DB performance issues we can revisit. I also worry about people with low-end CPUs such as NAS boxes. ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 http://forums.slimdevices.com/showthread.php?t=21984 http://forums.slimdevices.com/showthread.php?t=14453 http://forums.slimdevices.com/showthread.php?t=1348 and some of these refer to other threads that I haven't bothered to dig up. If I've missed anything, I'm sure those involved would be more than happy to reiterate or contradict their previous statements. Can I assume that the position is approximately as follows. It is agreed the splitting things up is certainly worthwhile, but that pre Perl 5.8, it really isn't practical, and requiring Perl 5.8 wasn't acceptable. Perl 5.8 introduced suitable threading, and the split-scanner is based upon this. The intention for version 7 is to move over to apache / mod_perl, which will make threading far easier. My view is that it would be nice to have multiple threads each serving requests seperately. I would envisage having one thread per connected squeezebox. SlimServer would create a suitable sized pool of such threads when it started, and each would be allocated a squeezebox to serve as they connected. This way, the user interface would always feel responsive, and would hopefully prevent stuttery scrolling, poor time display etc. Any code that does something slow would only block the user interface actually calling that code, and would leave other users unaffected. The option of whether to update this code to work asynchronously could then be made based upon whether blocking, and the time delay was acceptable, rather than having to ensure that no code ever ran for an unnacceptable time. One could for example choose to dispatch a thread to perform the database lookups on track listings, whilst allowing the user to cancel before the lookup completed. Similarly, the web interface would have a pool of threads, each serving requests, as would the CLI. Finally, there would be a low priority thread resposible for maintaining the database and keeping it up to date, and scanning as required. As an aside, it struck me that it might be quite nice to have the scanner build up a completely new database content during a rescan. Only when the rescan completed would the new content be used, so that performing a rescan could be done slowly with very low priority, without affecting the user too much. The model above is I believe how most servers operate, certainly Apache, MySQL etc, and seems quite sensible. From what I've understood of the Perl threading system, this isn't too hard to implement, although converting SlimServer would be very much tougher. I've tried to do some research on how Apache / mod_perl work, and it looks like this solution would effectively implement what is detailed above. Apache would create threads to deal with each SlimProto connection request, and would obviously do the same with web requests. I presume that it would also be possible / desirable to have apache create a separate thread to serve each stream request. Chris Key ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 0.5 : 1.35109996795654 2006-05-08 19:45:17.5286 Timer Task 0.5 : 0.580141067504883 2006-05-08 19:45:17.5305 Scrobbler::BackgroundHTTP::readHeader 2006-05-08 19:45:17.5325 Response Time 0.5 : 0.584939002990723 3rd party plugins causing the dropouts can be a real problem, but thanks to perfwarn we can find the problem code better. :) Also, I wonder why this plugin has its own HTTP implementation? Maybe it was pre-SimpleAsyncHTTP, but it could be updated to take advantage of the new HTTP code. ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 on it. I do run Samba on it, so we can easily move ripped files to it, but its just a slimserver. It has sshd and a few other things, but nothing of note, zero users ever, no apache, postfix or any of that stuff. Its AMD Athlon(tm) 3000+ with a gig of ram. So, my feeling is that this is the SlimServer failing to keep PCM data flowing down the wire to the SB1. I could be wrong. My collection is ~750 CDs, nealy 99% flac. spread over 4 IDE drives. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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, but this has potential. -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 complicated and have a lot of loops. I wonder if we could make our TT processing more friendly by using our own Template::Context or Template::Document subclass that throws in some calls to idleStreams. These are called once for each template, and since most/ all of our templates use a lot of wrappers, includes, processes, etc, this might help. Also, slow database queries resulting from web requests are also a problem (maybe even a bigger problem). The only way to solve this is to move DBI queries into another process so they don't block the main loop, ala POE's EasyDBI. http://search.cpan.org/~abw/Template-Toolkit-2.14/lib/Template/Manual/ Internals.pod ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 templates can take some time, especially if they are complicated and have a lot of loops. I wonder if we could make our TT processing more friendly by using our own Template::Context or Template::Document subclass that throws in some calls to idleStreams. These are called once for each template, and since most/all of our templates use a lot of wrappers, includes, processes, etc, this might help. Also, slow database queries resulting from web requests are also a problem (maybe even a bigger problem). The only way to solve this is to move DBI queries into another process so they don't block the main loop, ala POE's EasyDBI. I should also point out that with the upcoming move to DBIx::Class and MySQL we'll see much improved database performance as well. :) ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 out some ideas. :) ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 priority. I was just throwing out some ideas. :) 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. Chris Key ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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. Hmmm, at the risk of sounding churlish, for me it's actually both. The web interface is nowhere like as responsive as I feel it should be. But whilst it's annoying, that's something I can live with - the music pausing is what really drives me nuts. 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 systems and see if you notice any improvement. ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 scanning, not that the web interface is sluggish. Hmmm, at the risk of sounding churlish, for me it's actually both. The web interface is nowhere like as responsive as I feel it should be. But whilst it's annoying, that's something I can live with - the music pausing is what really drives me nuts. 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 systems and see if you notice any improvement. I moved this from my test server to my real slimserver, and I still get dropouts when hitting a database-intensive page such as Browse Albums. :( This is clearly DBI blocking everything. ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 sure that's necessary. I see this as well (to the extent I avoid the web interface altogether while playing, which is a shame), and I suspect the stalls are simply because the main application thread (which also currently streams audio to the players) is taking too long between each fill operation. I suspect that's as much IO wait time as pure CPU hogging - eg if the database is thrashing the disk doing a search then the CPU probably won't be maxed out, but because of the architecture that spare CPU time won't be used to fill the players. Filling the players is actually a very low-CPU-use activity (even with transcoding it takes surprising little CPU to stream over the network). I wouldn't be surprised if simply breaking out the player streaming to another thread/process would solve this problem without having to mess around with priorities at all. I've personally looked around to try to increase the socket buffer size within the server to try to compensate as I'm convinced that the stuttering I get is because of the server not filling the server-side socket quick enough, rather than because the network bandwidth has become exhausted. Given that it takes almost no CPU to then get that data over the network I was hoping this would effectively extend the SB1's limited buffer. I didn't have any joy with that approach, though. 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. However, I know the Slim Devices developers have looked into it quite a bit more than I have so they may have much better evidence than my simple gut feel as to why the current development is the right one. I suspect such an architectural change would become easier once the main pain of moving the scanning out has been taken, because that will already have proved a multi-process architecture that shares access to the database successfully. Once that's done it doesn't sound too complex to have a small separate process/thread that reads the top of the playlist from the database and streams that out (with any transcoding necessary). Does anyone know of a bug for this in Bugzilla? If not it might be worth creating one so that it could be voted for. I'm (fortunately) not suffering dropouts --- am I right in thinking that the SB2/3 have larger internal buffers? The main issue is that slimserver does seem to make the computer generally less responsive, regardless of whether it's actually streaming at the time. It would hence be nice to be able to have the time critical bits running with a high priority, making the system nice and responsive, and to have the CPU intensive, less time critical bits running with a lower priority so as not to interfere with normal computer usage. I presume that as the effort is going into splitting off the scanning, that that's where most of the CPU is going, and that once that's done, the occasional CPU hogging will cease. Nevertheless, it does seem to make sense to split off the streaming so that one doesn't have to worry too much about slower tasks elsewhere. I don't really know what involved in the following, but I'd be interested to hear some opinions on whether there's any merit in splitting things up somewhat more, having threads for: Streaming; The web interface; Scanning; Each connected client. This would mean that any slow operations, whilst potentially taking a while to return, would not grossly affect other users. Even with a relatively small music collection, some operations are fairly slow to respond, with delays of up to a few seconds. This isn't a problem with one squeezebox, but with several, I can imagine it could get really quite annoying to have the display freeze whenever another user was doing something slow. Chris Key ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
RE: [SlimDevices: Beta] Re: SB1's struggling to keep up
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
Re: [SlimDevices: Beta] Re: SB1's struggling to keep up
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 * 2; This won't make the server go any faster, but does seem to make use of a larger tcp buffer in linux 2.6 Done. Let me listen a bit and I'll let you know. Thanks Pat -- Pat http://www.pfarrell.com/music/slimserver/slimsoftware.html ___ beta mailing list beta@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/beta
