Hmm... I'm not sure I fully understand the issue, can't reproduce it.
I've enabled the "no kids music" library as the default view. Then I
browse Artists -> All Albums. Takes about two seconds in the web UI,
less than a second in iPeng. I tried both, the unified list as well as
the separate Album Artist/All Artists lists.
...
Can you check the resources to figure out whether it's memory, disk IO
or CPU bound?
Artists->All Albums is fast for me, too, it's "Album Artists->All
Artists" that is slow.
More confusion... how would I get that menu item? I don't have an All
Artists item in the Album Artists list.
It's CPU (one core maxed out for the whole time of the query). All other
figures are low (176 MB RAM, very little disc IO to my flash drive...)
Subsequent queries of the same page are much, much faster and consume
Keep in mind that browse pages (web UI) are cached. Once you've been
there it would just pull the fully rendered page from the cache. No
database lookup involved. You can prevent this using the --nobrowsecache
parameter.
less CPU although still slower than "Artists->All Albums", it seems to
be primarily the first load after selecting the filtered library (in
"Library Views") that is so extremely slow (stays slow until I have
completely loaded the list at least once). So to reproduce it you might
have to switch your libraries.
BTW, after switching libraries "Album Artists->All Albums" is slow even
with the unfiltered library, albeit not as extreme as for the filtered
one.
Now you say it was "Album Artists -> All ALBUMS", too?
[15-01-13 13:20:14.0735] Slim::Control::Queries::albumsQuery (671) Albums query:
SELECT albums.discc AS 'albums.discc', contributors.name AS 'contributors.name',
contributors.namesort AS 'contributors.namesort', albums.disc AS 'albums.disc',
albums.titlesort AS 'albums.titlesort', albums.titlesearch AS 'albums.titlesearch',
albums.contributor AS 'albums.contributor', albums.id AS 'albums.id', albums.title AS
'albums.title', albums.artwork AS 'albums.artwork', albums.compilation AS
'albums.compilation', albums.year AS 'albums.year' FROM albums JOIN contributor_album ON
contributor_album.album = albums.id JOIN contributors ON contributors.id =
contributor_album.contributor JOIN tracks ON tracks.album = albums.id JOIN library_track
ON library_track.track = tracks.id WHERE contributor_album.role IN (?, ?) AND
library_track.library = ? GROUP BY albums.id ORDER BY contributors.namesort COLLATE en_US
, albums.year, albums.titlesort COLLATE en_US LIMIT ?,? / [5, 1, "9e75b8cb",
10
0, 100]
That's a query for albums, while the next one is a contributor query:
[15-01-13 13:18:13.4218] Slim::Control::Queries::artistsQuery (1130) Artists
query: SELECT contributors.id, contributors.name, contributors.namesort FROM
contributors JOIN contributor_album ON contributor_album.contributor =
contributors.id WHERE
contributors.id IN (
SELECT DISTINCT
contributor_track.contributor
FROM contributor_track
WHERE (contributor_track.role IN
(5,1,4,2,3,6) ) AND contributor_track.track IN (
SELECT library_track.track
FROM library_track
WHERE library_track.library = ?
)
)
GROUP BY contributors.id ORDER BY contributors.namesort
COLLATE en_US LIMIT ?,? / ["9e75b8cb", 6600, 500]
These can't be compared, obviously.
[15-01-13 13:21:38.7187] Slim::Schema::Debug::query_start (23) SELECT me.id,
me.type, me.name, me.active, me.total, me.done, me.start, me.finish, me.info
FROM progress me WHERE ( type = ? ) ORDER BY start,id: 'importer'
The Settings/Information page still open? It's the progress display for
the last/running scan.
"My Music" settings:
A few differences to mine. Will double-check. Thanks!
--
Michael
_______________________________________________
beta mailing list
beta@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/beta
