slimserver has been messing with my head
however tonight i tried firefox rather than safari, and huge
performance improvements (on both 6.2.1 and 6.2.2 - have just gone back
to 6.2.1 as seemed to be getting some choppy audio with the 09/02
build)
no idea why of course!
for ref, mac mini, 512MB
Just downloaded the nightly with this change and the UI is so much more
responsive it incredible. Re-scans also seem to be faster.
Still had to downgrade to FW28, as 29 doesn't work with my router.
--
oreillymj
oreillymj'
This temporary fix has been made an official option in the latest
nightly.
6.2.2 or 6.5?
Both.
--
Michael
---
Help translate SlimServer by using the
StringEditor Plugin (http://www.herger.net/slim/)
_
mherger Wrote:
> This temporary fix has been made an official option in the latest
> nightly.
6.2.2 or 6.5?
--
Michaelwagner
Michaelwagner's Profile: http://forums.slimdevices.com/member.php?userid=428
View this thread: h
I like the idea of being able to suppress the stats display. Who in the
world needs to be reminded of this on every single page? Put it on a
single page in the server setup and then nobody will really care how
slow it is.
--
JJZolx
Jim
meyergru Wrote:
>
> A temporary fix would be to edit %SLIMSERVER%/Slim/Web/Pages.pm at line
> 188-190 where it says:
>
> $params->{'song_count'} = _lcPlural($ds->count('track',
> $find), 'SONG', 'SONGS');
>
> Change those three lines to read:
>
> $params->{'song_count'} = 0;
>
This temp
Me again.
The fact is that with large databases, a massive improvement can be
seen from avoiding the scans in Pages.pm.
As far as I can tell that scan is being done for any skin whatsoever,
even if the statistics info is not being used after it was generated.
If some people experience skin- or
On 10/28/05, kdf <[EMAIL PROTECTED]> wrote:
> Once I can make sense of all of Jacobs
> work, I'm hoping to find the time to make a fishbone2 using the ajax
> tools (and maybe skin inheritance once implemented in 6.5)
I'm definitely waiting for the skin inheritance feature before putting
up Default
Its a fair price. How can anyone look a gift horse in the mouth!
--
MrC
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
On 28-Oct-05, at 5:53 PM, MrC wrote:
Load times are consistently lightning fast with Lite. I can generate
the stalls frequently (sorry KDF) with Fishbone. ExBrowse3 seems
fine.
the price you pay for my bad code and my desire to have all those
commands one click away ;) Once I can make sens
dean Wrote:
> Does the skin make a difference? How are the load times on the EN
> (Lite) skin?
Yes, skin seems be a factor, as does browser.
Lite is very fast, never stalls.
ExBrowse3 seems fine too.
Fishbone (sorry KDF) seems to stall as much as 18 seconds on Opera and
Firefox. Never on
dean Wrote:
> Does the skin make a difference? How are the load times on the EN
> (Lite) skin?
It sure does!
Load times are consistently lightning fast with Lite. I can generate
the stalls frequently (sorry KDF) with Fishbone. ExBrowse3 seems
fine.
It also seems to depend on browser. I ca
* MrC shaped the electrons to say...
Yeah, understood, and that's what I suspected too. So, the question
is, what's going on underneath the covers that makes this thing hicup
every now and again? There are long, unpredicatable stalls.
That is an interesting question.. :)
Anyway, I'm not m
Does the skin make a difference? How are the load times on the EN
(Lite) skin?
On Oct 28, 2005, at 4:43 PM, MrC wrote:
Dan Sully Wrote:
Keep in mind that the time displayed is from immediately before
generating
the page to immediately after. It doesn't take into account transfer
time
aft
Dan Sully Wrote:
> Keep in mind that the time displayed is from immediately before
> generating
> the page to immediately after. It doesn't take into account transfer
> time
> afterwards to send the page to your browser.
>
Yeah, understood, and that's what I suspected too. So, the question
is,
* MrC shaped the electrons to say...
I just tried running some tests with your web page timer code. There
is something else going on, that is not being included in your times.
Most pages took anywhere from .5 to 3 seconds to load in my test.
Then, I closed the page in my browser, and re-opene
Dan,
I just tried running some tests with your web page timer code. There
is something else going on, that is not being included in your times.
Most pages took anywhere from .5 to 3 seconds to load in my test.
Then, I closed the page in my browser, and re-opened a page to the
server. It took
Hello Dan,
MySQL 4.1.12 dump file available at
ftp://sirius.mizel.net/pub/slimserver.dump (anonymous login)
SlimServer Version: 6.2.0 - 4753 - Linux - EN - utf8
Nicolas
--
nmizel
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.s
slimserversql.db file emailed to you Dan
--
mikerob
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
* meyergru shaped the electrons to say...
That might save the full table scan for calculating song_count, but the
scans for album_count and artist_count are still being done, so may this
is why you don't see much improvement from that correction.
Can someone with this slow down issue please se
There's little impact with my test notebook's 500 songs, though...
That might save the full table scan for calculating song_count, but the
scans for album_count and artist_count are still being done, so may this
If I remember right it saved the full scan for all but artist_count. (2
out of 3
mherger Wrote:
> >
> There's an optimisation in DBIStore.pm around page 325:
> # Optimize the all case
> if (scalar(keys %findCriteria) == 0) {
>
> I don't know how much this would speed up the count. But it's rarely
> used
> as Pages.pm adds the contributor.role to %findCriteria
We need to do a full scan with joins to get the proper counts - as now
things
like including composer, etc and various artist albums are dynamic.
There's an optimisation in DBIStore.pm around page 325:
# Optimize the all case
if (scalar(keys %findCriteria) == 0) {
I don't know
O.K. So there.
Apply this diff to .../Slim/Web/Pages.pm:
Code:
*** Slim/Web/Pages.pm.orig Mon Oct 24 23:47:21 2005
--- Slim/Web/Pages.pmThu Oct 27 22:15:26 2005
***
*** 157,162
--- 157,171
return sprintf("%s %s", $count, $wor
Ok...lines 188-190 are now as follows:
$params->{'song_count'} = 0;
$params->{'artist_count'} = 0;
$params->{'album_count'} = 0;
The startpage loads much quicker. Why do I still have my Album, Song,
and Artist counts populated on the start page? I was going to add my
own code to store this inf
I opened bug 2385 http://bugs.slimdevices.com/show_bug.cgi?id=2385 for
this problem.
--
nmizel
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
meyergru Wrote:
>
> A temporary fix would be to edit %SLIMSERVER%/Slim/Web/Pages.pm at line
> 188-190 where it says:
>
> $params->{'song_count'} = _lcPlural($ds->count('track',
> $find), 'SONG', 'SONGS');
> $params->{'artist_count'} = _lcPlural($ds->count('contributor',
> $find), 'ARTIST', 'A
mikerob Wrote:
>
> I totally agree that I only see the justification to check the music
> library stats when you do something to change them. With me, that's
> only when I do a rescan as I don't use iTunes, composer, various
> artists or compilation album features.
No, that is not the only opp
meyergru Wrote:
>
>
> The reason you experience this with a relatively small number of songs
> may be that your machine is not too fast, especially the harddisk
> (quote: "Since hard disk performance is the Mini's worst attribute, it
> makes sense for Apple to offer a faster disk for a bit more
mikerob Wrote:
>
> What debug information would be useful to find out what is going on?
No debug info needed any more. We already know what is going on.
There is a full database scan done in 6.2 in order to display the
statistic information on the start page (i.e. # of songs, albums,
artists).
Just to echo others' comments, I've seen an massive slow-down in browser
response with 6.2.
It is taking 10-15 seconds to navigate between browser pages and the
search function is taking 30-40 seconds to return results.
I'm running OSX 10.4.2 on a 1.42 GHz Mac Mini / 1G RAM - the Mac is
only use
meyergru Wrote:
> Voila. Several seconds saved on every web page access.
SlimDevices... give this bloke a job... but I guess he probably doesn't
need one.
MC
--
ModelCitizen
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevi
Dan Sully Wrote:
>
> The data doesn't change without a rescan / adding new music via Browse
> Music Folder.
>
> However - we have dynamic views on that data. If a user doesn't want to
> display any Composers in their artist list, that's a setting that can be
> changed. The Artist count number w
* docbee shaped the electrons to say...
Dan, I don't use iTunes, maybe that's the reason why I don't understand.
Do you really mean that the number of albums and artists does change in
the database without doing a rescan? I had the impression that the only
way to get things in/out is by initiati
Just for testing purpose I changed the following lines in Pages.pm to
get rid of the stats sql traffic each time the startpage is displayed.
lines 188-190 changed to:
$params->{'song_count'} = 'any';
$params->{'artist_count'} = 'any';
$params->{'album_count'} = 'any';
and voila, now the start
Dan Sully Wrote:
>
> We need to do a full scan with joins to get the proper counts - as now
> things like including composer, etc and various artist albums are
> dynamic.
>
They are dynamic? Why? I thought that there were very limited occasions
on where modfiying accesses are needed for a musi
Dan, I don't use iTunes, maybe that's the reason why I don't understand.
Do you really mean that the number of albums and artists does change in
the database without doing a rescan? I had the impression that the only
way to get things in/out is by initiating a rescan and therefore the
stats comput
* meyergru shaped the electrons to say...
So I guess this explains the full table scans for the stats...
We need to do a full scan with joins to get the proper counts - as now things
like including composer, etc and various artist albums are dynamic.
People seem to like to complain that it's
Ben Sandee Wrote:
>
> FWIW, I made the same change on my system and didn't see any
> improvement at
> all (not that I was complaining about performance in the first place --
> I
> wasn't). So YMMV. :-)
>
> Debian Sarge, Kernel 2.6.11, Athlon 800mhz, 512mb RAM, 1000 albums MP3
>
>
Sure. 1000
Ben, if you don't had an issue before it is no surprise to me that you
don't see an improvement. Just put another 2000 albums on top an join
the club...
--
docbee
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/list
On 10/26/05, docbee <[EMAIL PROTECTED]> wrote:
I gave it a try and the application now behaves much crisper :-) Whatstill bothers me is the long delay it takes to connect to theslimserver homepage for the first time.I can hardly believe that slimserver does count all the titles, albums,
etc via sql
I gave it a try and the application now behaves much crisper :-) What
still bothers me is the long delay it takes to connect to the
slimserver homepage for the first time.
I can hardly believe that slimserver does count all the titles, albums,
etc via sql and is not storing these values. The onl
That is good news. I will try this. Too good to be true, or to take it
the other way round: argghhh!
--
docbee
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
Aha. The display of the number of songs on the start page explains the
read accesses.
I dug into the subject a little further and tried DBD::RAM (which is
outdated and does not work any more) and DBD::AnyData instead of
SQLite. To my dismay, I found that AnyData speaks a slightly different
SQL di
@mherger: no plugins like moodlogic, musicmagic, etc. How many titles
do you have in your archive? Maybe you are on the lucky side because of
a smaller database?
It is smaller: about 6500.
Is there an option to tell slimserver not to use sqllite but to hold
everything in memory? If so, I would
For my part I noticed a slight overall speed increase compared to 6.1,
except when the server refreshes the home page and re-count the number
of albums / songs / artists.
I then occasionally get dropouts (ok, I have a slow hardware, but
still...). If I remember right, this information used to be
@jlynch3: the box delivers other web content at no delay. Just
slimserver is behaving that slow.
@mherger: no plugins like moodlogic, musicmagic, etc. How many titles
do you have in your archive? Maybe you are on the lucky side because of
a smaller database?
@kdf: sorry I don't want to be unfair
Hi folks!
I can see the same behaviour as docbee: Slimserver 6.2 seems pretty
slow for normal browser accesses. I have traced Slimserver with strace
and found some strange things happening.
Even when I just browse to http://slimserver:9000 (not only on first
occurrence), there are really long s
It seems you're running a bit light on the RAM side. Do you serve other
web content from the box? How quick does that come down?
--
jlynch3
___
Discuss mailing list
Discuss@lists.slimdevices.com
http://lists.slimdevices.com/lists/listinfo/discuss
49 matches
Mail list logo
