Jump to content

Increasing Performance on Large Collections (Especially Album Artist)


ginjaninja
 Share

Recommended Posts

ginjaninja

have the devs been able to consider browsing improvements around music album artists on large collections?

for my 700 album artists it is unworkable. The delay is over 30 seconds and more often than not the ui plays up or .the screensaver kicks in whilst waiting.

 

one solution might be for client to cache the music top level responses and the ui refer to the cached response with a lazy refresh in background at the server apis leisure..

alternatively if number of objects is greater than X, then display a first letter jump in list rather than flat list.

thoughts?

Link to comment
Share on other sites

  • 2 weeks later...
chessdragon136

@@ginjaninja - Regarding music sluggishness, in the next release I have disabled image retrieval for music - I want to see if this drastically speeds up the app.

If it does, I will try get the server tagging elements in for images so that should stop it re-rendering images each time and only do it on the first view. That will help.

 

If this doesn't speed it up, then its the server return of all the items in the array that is slow, so will need to implement an A-Z like you suggest. 

Edited by chessdragon136
  • Like 1
Link to comment
Share on other sites

ginjaninja

@@ginjaninja - Regarding music sluggishness, in the next release I have disabled image retrieval for music - I want to see if this drastically speeds up the app.

If it does, I will try get the server tagging elements in for images so that should stop it re-rendering images each time and only do it on the first view. That will help.

 

If this doesn't speed it up, then its the server return of all the items in the array that is slow, so will need to implement an A-Z like you suggest. 

thankyou for persevering

 

..FWIW browsing under dlna on samsung tv (no artist images, no caching between sessions) is quick enough just (c. 3 secs for 700 album artists) the first time and lightning quick returning to previous views in session (presumably the dlna client is caching the responses in session).

Interestingly bubbleupnp (dlna) does, for the  all album artist view,  return images in a very speedy fashion, i think there is something asyncronous between where in the view the user is and retrieval / display of images...ie it doesnt try to do everything in one go before returning control to the user...this yields a very pleasant user experience. I think bubbleupnp also caches images even after the session has finished.

 

This leads me to think that

a) large database queries (no image metadata) for mb3 are just about quick enough for the server for many album artists...***

B) image retrievable of those album artists through MB3 is not lightning quick, but can be very acceptable with an optimal ui design/client caching

 

I look forward to testing the release.

 

FWIW2 *** IMO all the clients would probably benefit from chunking up all movies, all shows, all artists, all album artists, ie all everything, into 'Letters'

...not understanding the intricacies of ui design , i suggest (assuming that requesting 'total number' was  trivial) if total objects is > X (X=possibly an option to user) then present letters rather than all objects. The Roku UI provides 'letter lists' very well however on some screens, letter lists sit next to an all object list (to the detriment of the letter list as you have to wait for 'all object list' to return before use).

IMO when browsing the library for something i know i want - letters are always faster and preferred. When browsing for something i dont know i want then 'all object lists' are sometimes preferred.

..this would translate into following suggestions (please forgive my naivety on ui design)...

  • By Default all library content view choices are of the grouped/subquery kind (eg Letter, Genre, Year, Suggested/Next Up, Latest, Search Result) , with  the all object kind as a choice for special cases / masochists .
  • If an all object view is not explicitly chosen by the user (in which case do show all objects and hang the performance implications) but needs to be shown (due to design considerations) then group objects into letters if number of objects > X (or in any case)
  • Avoid 'All object lists' and letter choices on the same UI (like the roku)
Edited by ginjaninja
Link to comment
Share on other sites

ginjaninja

Ha..got it wrong as usual...
It would seem that of the 40 seconds it used to take to return album artists....only 8 seconds is attributable to images...surprising.

Or to put it more clearly..for .570.(no images)..roughly
The album view is 2 seconds quicker..now 1 second (guesstimate)
The artist view doesnt work ..selection does nothing..(might not be new issue)
The album artist view is c.8 seconds quicker at now 32 seconds

Take old state with pinch of salt (taken from memory)


It should be said that the album view contained more objects (2676 vs 700) pre 0.570 but was still fast...so contradicting the penulimate post...the images dont seem deciding factor...but then why is dlna on samsung faster...
Maybe related to album artist view also showing albums frame...

 

the pre 0.570 (and to a great extent the 0.570) performance...matches the web client.....Albums retrieve quickly and albumartists retrieve slowly by a factor of at least 10 (100 albums vs 100 albumartists)....

Edited by ginjaninja
Link to comment
Share on other sites

chessdragon136

These times you're quoting - that are the start and end points you're measuring?

Link to comment
Share on other sites

ginjaninja

Ok update and test again please

0.570c

album view seems a few milliseconds faster.

albumartist view the same...32+ seconds...

 

PS dont discount the possibility that the issue is with the server...the logs reports ms per database request and albumartist requests take a significantly longer time.....that said samsung dlna/bubble upnp dlna uis are much perkier......

Edited by ginjaninja
Link to comment
Share on other sites

chessdragon136

how long do the requests take in the log? 

Just 30 seconds is a long time computationally! I can't replicate any viable difference in speed but i have a smaller collection. 

 

When it does load, are the correct albums returned?

Link to comment
Share on other sites

FrostByte

I can confirm it takes a long time to retrieve artist and album artist information.  I thought it was broke there for awhile.

Link to comment
Share on other sites

chessdragon136

Ok I've just pushed out v0.570d - I''ve added some time logging into the AlbumArtist page - can you load it, then go to the logs and give me the details please

Link to comment
Share on other sites

CBers

@@FrostByte - do you use Cover Art?

 

I noticed last (during a short test after the update) that it took a long time to display movie posters etc in the Movie and Collections screens.

 

I was wondering if it was CA delaying the load as it has to "treat" them on the fly.

Link to comment
Share on other sites

ginjaninja

0.570d

Load..goto log..clear...goto music...(albums shown) ..goto albumartists...return to log..

Log shows..

Loading:GuiPage_MusicArtist:Time0

Loading:GuiPage_MusicArtist:Time 46005ms

Loading:GuiPage_MusicArtist:Time 46065ms...

 

Points of note

Log doesnt distinguish different pages

Why two 46000ms? The user only experienced 1 set of delay..

I cant count in my head very well..looks like wait is a bit longer than previously reported.

The album order is not intelligable on the album view..

The albumartist order is correct ie. Alphabetical.

The album order on the albumartist view is the best of any client...non albums first (alphabetically)..then album artist albums (alphabetically)

Link to comment
Share on other sites

chessdragon136

Ok loaded v0.570e

 

The only page affected is  the Album Artist view - forget about everything else for now - I've also updated the logging to reflect what the times show. 

 

I have made an EXPERIMENTAL change to Album Artist where only the first 200 items are initially loaded, then the rest follow but this should allow for user control to navigate those 200 until the rest load, saving a lot of waiting. 

 

Can you please update and go to the album artist page - The counter will initially say 1 / 200 - stay on the page until the 200 updates to the correct number. Then hit the logs and give me the data :)

Link to comment
Share on other sites

ginjaninja

User control time 13741ms

Getting additionL data > 200 items 13760ms

 

User control was indeed returned much quicker.. (about 13741 ms)..

The additional items never show...i waiting over 1 minute (not pressing anything)..the screensaver kicked in.

Went to bottom of list to check..only 200.

 

I think the goal for any ui change would be in order of <2 seconds..to keep ui feeling fluid..although an egg timer/progress bar might allow more leeway..good to see the time coming down...but it does seem that returning 200 album artists in much slower than 2676 albums..1sec for 2676 albums..13 secs for 200 album artists..over 100 times quicker..

Link to comment
Share on other sites

FrostByte

@CBers no I do not use cover art., but I have noticed poster images loading slower in movies and collections also at times.  Some of them will show and then shortly after the rest pop up.  Not sure what that is, could be many things I suppose.  With Album Artists (I have almost 900) it was like nothing was happening and I wasn't sure if it was even working it was so slow.  Updating to 570e now.

  • Like 1
Link to comment
Share on other sites

chessdragon136

Yeah it was experimental and has been changed so the next 200 items only load when needed and will lock the UI while doing so - makes it stable.

 

Your target is not right though -> if it takes 14 seconds to load 200 then i can only load what, 30 items in your <2 second load time. That's barely a screen full.

Given I can parse json for larger objects on other pages much faster, and this page has no different code, then i can only assume that the slowness is in the network and server to process the request, which is out of my control. 

 

Can you go to the server logs and see how long the request is taking to process server side

Link to comment
Share on other sites

chessdragon136

Ok just uploaded v0.570f - Try again and let me know.

Implementations have been made on Series Page & Music Album Artist ( covers all tv, films, music pages for the most part)

  • Like 1
Link to comment
Share on other sites

ginjaninja

From server log .570e
Difficult to isolate the request but the large two were
2015-03-08 11:39:59.0812 Debug - HttpServer: HTTP Response 200 to 192.168.4.127. Response time: 7943.4335 ms.
2015-03-08 11:40:10.3871 Debug - HttpServer: HTTP Response 200 to 192.168.4.127. Response time: 11299.9349 ms.


Doh.missed urls..are these the right ones?
2015-03-08 11:39:59.0812 Debug - HttpServer: HTTP Response 200 to 192.168.4.127. Response time: 7943.4335 ms.
Url: //192.168.4.130:8096/mediabrowser/Artists/AlbumArtists?format=json&SortBy=SortName&SortOrder=Ascending&Recursive=true&ExcludeLocationTypes=Virtual&Fields=ParentId,SortName&userId=59543acb15f7ccd6012f4447c75b0cf2&Limit=0

2015-03-08 11:40:10.3871 Debug - HttpServer: HTTP Response 200 to 192.168.4.127. Response time: 11299.9349 ms.
Url: //192.168.4.130:8096/mediabrowser/Artists/AlbumArtists?format=json&SortBy=SortName&SortOrder=Ascending&Recursive=true&ExcludeLocationTypes=Virtual&Fields=ParentId,SortName&userId=59543acb15f7ccd6012f4447c75b0cf2&Limit=200

The speed is similar to webclient on server..so i think the server is slow for album artist requests...and clients need to be very cute to deal with the inefficiency. Unless the devs can improve the server

Will check next release

Edited by chessdragon136
Removed http to see entire link
Link to comment
Share on other sites

chessdragon136

Ok it is server side, and there really is nothing i can do client side beyond what I've implemented, to chunk it into 200 items (can make that smaller if required) I can remove the first call to get the item count to speed it up a touch more. 

 

@@ebr - Sorry to bring you in on this, but I need some advice - Why would the server be soo slow, are the URL's I'm requesting unreasonable? Given the web client is apparently just as bad, is there a known issue with album artist being ridiculously slow?

 

Looking at the links, it takes 8 seconds to calculate how many album artists there are. The limit 0 means i am returning 0 data back to the app bar this number

It then takes 11.5 seconds to then bring back the 200 items (so 3.5 seconds to get the http back to the app and process to json, 8 seconds to calculate server side essentially) 

Link to comment
Share on other sites

ginjaninja

0.570f

Albums and album artists load in chunks

Album chunks are instananeous...

Album artist chunks..1st chunk..13secs..2nd chunk c.13 secs..ui becomes v unstable..cant actually utilise 2nd chunk..whats presented and whats underneath dont match..after 2nd chunk finishes loading..think im back on albums.

Link to comment
Share on other sites

chessdragon136

Ok try version G 

 

Explain what you mean by the last statement? 

Link to comment
Share on other sites

CBers

@CBers no I do not use cover art., but I have noticed poster images loading slower in movies and collections also at times. Some of them will show and then shortly after the rest pop up. Not sure what that is, could be many things I suppose.

Seems OK today, so might have been the server doing stuff.

Link to comment
Share on other sites

ginjaninja

Tried 0.570g..

Albumartist chunks now reported in samsung log as 11-12000 ms...a bit quicker..

 

What i meant by previous statements was..

I go to album artist..first chunk displays..i scroll down to last row of album artists (ie the row with 200th)..i scroll down one more row..loading..wait12 seconds...the ui shows im on next row (ella fitzgerald selected artist 201) ...i press ok...im in an album by another artist...i press return/back..im in the album view..

But the ui has started to break down..the controls stop registering an expected effect...no cursor on screen..but ok yields a result..im in another album..playing a track...cant return to home screen or bring up tools menu...client hasnt crashed..the screen saver kicks in...press a few more keypresses..eventually get tools menu...click home..i seem to be back in control..whats on screen/cursor matches my input.

 

 

Chunking on album view works/yields expected result...after chunk loads navigation proceeds as expected..

Edited by ginjaninja
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...