Bug 708 - browse music folder INSANELY slow and cpu intensive
: browse music folder INSANELY slow and cpu intensive
Status: RESOLVED DUPLICATE of bug 874
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 5.x or older
: PC All
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-03 15:22 UTC by Kevin Pearsall
Modified: 2008-12-18 11:50 UTC (History)
0 users

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Pearsall 2004-12-03 15:22:03 UTC
on my linux system, browse music folder is very useless.  you click browse music
folder in the web interface, and up to 10 minutes later the page loads.  but
there isn't even enough content on it to fill one whole web page.  during this
time, the server is also using 100% of the cpu.

running fedora core 2, kernel 2.6.8-1
slimserver from cvs as of 12/2/04
p4 2.8ghz/800fsb, 1gb of ram
library is all flac, about 6000 songs currently, but i was testing this with a
small (just various artists albums) folder of 11gb of flac, 624 files.
Comment 1 KDF 2004-12-03 15:37:45 UTC
usually this is due to circular links.  I browse music folder all the time, and
I have not had any "insane"ly slow response. can't suggest much else.
Comment 2 KDF 2004-12-04 19:06:29 UTC
Can you supply more details of the files themselves?  Are these all single track
FLAC, no CUE sheets?  Are they full album with external CUE or internal CUE?  On
my setup, Mandrake 10, the closest I can do is 1000 mp3 files in a folder.  It
takes about 5 seconds to handle the page.  Is the music library database on?

even with a recursive link, I can't seem to reproduce anything close. I shudder
to think what d_info might look like for 10 minutes of activity.  The only
possibility I can think of might be that the folder scan isn't happening
properly (storable not working, perhaps) and entering the folder is triggering
the folder scan for 11gB of files.
Comment 3 Vidur Apparao 2005-01-24 12:27:48 UTC
I'm reassigning this one to Dan, since he's worked on Browse Music Folder
speedup after the database rework.

Kevin (Pearsall, not Deane-Freeman), are you seeing better behavior in more
recent 6.0 builds?
Comment 4 KDF 2005-02-26 14:04:06 UTC
putting this together with 874 since the end result should be the same.

*** This bug has been marked as a duplicate of 874 ***
Comment 5 Chris Owens 2008-12-18 11:50:18 UTC
Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.