Bug 1059 - Web interface hogging CPU
: Web interface hogging CPU
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Web Interface
: 6.0.0
: PC RedHat Linux
: P2 major (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-12 15:13 UTC by James Dunn
Modified: 2008-08-18 10:53 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description James Dunn 2005-03-12 15:13:34 UTC
Depsite a low background CPU usage (17-20%), when the server homepage is 
loaded, the CPU is 100% hogged to the point that the music stops playing.  Web 
update is very slow (7+ seconds) for a playlist of 58 items.
Closing browser allows music to start almost immediately but CPU is still 
hogged for several seconds after browser is clossed.
Both Linux an Windows XP have been reported to have the same issue in 6.01b.
Comment 1 Dan Sully 2005-03-13 19:07:05 UTC
What browser are you using?
Comment 2 James Dunn 2005-03-14 00:00:25 UTC
Browser is IE 6.0
Comment 3 Dan Sully 2005-03-14 00:07:25 UTC
Does this happen if you try using the Default2 skin?
Comment 4 James Dunn 2005-03-14 00:38:10 UTC
It works OK with Default2 - looks like a Fishbone skin problem then?
Comment 5 Dan Sully 2005-03-14 00:40:29 UTC
Could be - what about the default skin? Does it have the same behavior?
Comment 6 Dan Sully 2005-03-16 11:17:06 UTC
James - I've just checked in some changes to subversion change 2528, which
should alleviate the problem.

If you're tracking subversion, could you give it a try?

Otherwise the change will be in the 2005-03-17 build.

Thanks.
Comment 7 James Dunn 2005-03-17 15:51:04 UTC
Hi Dan, I tried the 17/3 nightly and I have the same problem - although it 
doesn't seem quite so bad.

Even when using the default skin, the music stutters.  It seems to be related 
to the amount of content in the panes - which is probably obvious I suppose.  
i.e. long playlists or album lists seem to create problems.

Cheers, James
Comment 8 Dan Sully 2005-03-17 15:53:25 UTC
That is correct, James. What is your itemsPerPage variable set at?
Comment 9 James Dunn 2005-03-17 16:00:52 UTC
It was 100 but I've dropped it to 30 and it seems well again.  I hope this 
helps track it down.
Cheers, James
Comment 10 Dan Sully 2005-03-17 16:10:22 UTC
Yes - that would do it. What type of CPU / Memory is on this system?
Comment 11 James Dunn 2005-03-17 23:56:35 UTC
It's a celeron 1.1 with 512MB memory.  It has 7 players attached (6 x SliMP3 +1 
Squeezebox - only one streaming when tests undertaken).  With no music playing, 
top shows about 8% to slimserver.  One MP3 playing to a slimp3 produces 27% 
which seems a little high to me.  Two different MP3s -> 2 x SliMP3 = 40%.
Despite using MySQL, I still see a 51MB memory footprint from 5700 tracks.
Comment 12 Dan Sully 2005-03-18 00:01:47 UTC
James - I've checked in quite a few changes today regarding memory usage and
leaking. The nightly build will kick off in 1 hour (9am your time), with those
changes.

Also - have you tried using SQLite? I believe it's quite a bit faster than MySQL.
Comment 13 James Dunn 2005-03-18 12:25:51 UTC
Thanks Dan, I'll give it a try - tomorrow most likely.

I already had MySQL installed so I didn't really want another running unless I 
have to.  The MySQL isn't really hitting the CPU (about 8% during scanning) and 
once scanning is done, I've not noticed any significant impact.  Browsing and 
searching seems fast enough to me so far.

I've also got ODBC gateways set up for MySQL so I'd rather keep it in use as I 
can pull off my collection and produce collection reports. Somethng I've not 
done since I used to use Jreceiver and some awful players (can't remember name)
that I had before Slim Devices came along :)

If it becomes an issue for me, I'll give SQLite a try.

Cheers,

James