Bug 1334 - Genre->Artist->Album navigation is slow
: Genre->Artist->Album navigation is slow
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Database
: 6.0.1
: Macintosh MacOS X 10
: P2 normal (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-08 08:00 UTC by Julius Friede
Modified: 2011-03-16 04:18 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 Julius Friede 2005-04-08 08:00:53 UTC
Overall, the official v6.0.1 release seems pretty good. Navigating down the tree
(i.e., Browse Genres->Genre->Artist->Album) is slow. There is a delay at each
step and the display refresh is �unsteady�, unlike v5.4.1, which was immediate
and smooth. Also, often when going from artist to album the display freezes
(none of the Slim remote commands are obeyed, and connection with the server is
lost. However this is not intentionally repeatable (the lost connection aspect).
Connection to the server (a wired SB with graphics display) also is
intermittently lost without any specific action being performed.

If it is any indication, when I first installed v6.0.1, the server was still
scanning my library (a large 20,000+ songs) after 3 hours. I lost patience and
restarted my computer. The scan then was completed in an expected time frame,
but my playlist were not found. A manual rescan solved that. All in all, a rough
start. My library is on an external firewire drive, but my playlists are stored
in the default location ~/user/Music/Playlists. My system is G4 AGP Sawtooth
450, 512 MB RAM, OS X 10.3.8, iTunes 4.7.1.
Comment 1 Nicolas Mizel 2005-04-08 14:47:51 UTC
Hi, as already mentioned in Bug# 1091, I also experience a slow web navigation, 
especially Album->Songs, where is takes about 2.5 seconds to list the 20 tracks 
of an album on a PIII 500 MHz running RedHat 9.

I also tried with MySQL, same result. It looks like the query itself is 
performing pretty fast, but something must be wrong with the html rendering 
routines. Setting the "Items Per Pages" to 5 solves the issue. Ok, this number 
is ridiculous, but I understand the same query is still executed, so this makes 
me think there's something wrong/unoptimized with the rendering.
Comment 2 Dan Sully 2005-04-08 16:53:09 UTC
Julius - are you referring to the Player UI, or the Web UI?
Comment 3 Julius Friede 2005-04-08 20:16:39 UTC
I was referring to the player UI, but they are both pretty slow. Just before
writing this I went to the web UI, selected Genre->Artist->Album, and I gave up
waiting for the album listing after about a minute (which is a long time for
something like this).
Comment 4 Blackketter Dean 2005-06-10 16:55:04 UTC
At that level, we should be just querying the album, which should be much faster.
Comment 5 Dan Sully 2005-06-13 21:04:49 UTC
Julius - I've checked in change 3388 to the 6.1 tree which has optimizations
when browsing down into the Genres tree, among others.
Comment 6 Chris Owens 2008-03-11 11:28:07 UTC
This bug was marked resolved in Slimserver 6.1, which is several versions ago.  If you're still seeing this bug, please re-open it.  Thanks!