Thank you for your donation!


UI responsiveness and scaling
#1
I hope I'm not repeating known information.  I'm having a fairly severe problem with the UI on android that I haven't seen discussed.  It can be very slow as detailed below.  I have seen the problem on raspberry pi 2,3,4, and with versions of moode from 5.3 to 6.4.

Since my setup is pretty vanilla, and I haven't seen this issue discussed, I tried to think about what is unusual in my system, and the only thing I come up with is repository size.  I began to see this problem when I hit about 220,000 tracks, and as my repository has grown, the problem has gotten much worse.  Hence the "scaling" in this thread title.
System setup (several systems tried as mentioned above, with similar issues):
moode server - raspberry pi 4, 4 GB, running moode 6.4.  No significant mods to moode or OS, configuration done via the moode interface. (ie I didn't f*** with it).
audio out via pi USB, no daughter board on the pi.
DAC - benchmark v3 (high end asynch DAC, a beautiful engineering achievement)
music source: moode mounts an NFS respository connected via gigabit ethernet.  The repository is on a pi 4b running NFS on raspbian. Tracks are mostly flac and DSD.  There are 2 NFS shares, both organized by genre/artist/album.
moode controller is android phone or tablet running firefox, opera mini, or chrome (tried all, opera mini seems to have the least slowness symptoms).  android versions mostly 6 and 7. I have used multiple phones and tablets and seen the same problems.  If I try controlling from a windows machine with firefox, the problem is significantly improved but not eliminated.  The controller is connected via a wireless bridge that was recently upgraded with no change in symptoms.
Symptoms
UI ignores touches, sometimes 4 or 5 times before one works.  If I'm on the playback screen and touch the top bar to go to the music sources page, it can take (literally) 5 seconds or more even if the touch works. The bar will highlight and then sit before responding to the touch and changing the page.   Somewhat aside, I long ago gave up trying to use the metadata source screen, which is quite slow, and instead just  browse/select tracks using the genre/artist/album folder structure.
Additional information
After struggling with this problem for a few weeks, I turned on minidlna and indexed the entire collection for upnp (this was done on the moode using the moode configuration tool, but I have used minidlna before (like moode, great software).  I installed a upnp controller (I like bubbleupnp for android), and configured the controller so moode was the upnp server and renderer.  This works great and there is no lag: in fact, it is lightning fast.  Same pi, same moode version and config, same client hardware, same repository, same network.

Taken together, the above suggests a scaling problem for large directories and repositories in moode that doesn't exist in minidlna and client using upnp.  I've chosen not to put a lot of moode technical configuration in this message, but am willing to dig, using the moode tools or ssh. I'd also be willing to run any suggested tests.
Reply
#2
The UI is rendered on the client-side web browser so responsiveness can very much depend on the size of the library against the speed of the hardware running the browser. There have been a couple of previous discussions on here about slow web interface response and generally it's been when old/slow mobile hardware is being used to run the browser.
I have a large library (>83000 tracks, ~8000 albums) and yes my tablet pauses whilst changing into the unfiltered tag and album views, especially after the library has been updated and the browser cache has refreshed but it's not unmanageable, my phone is much quicker being faster, more recent hardware.

If you're finding that your phone isn't fast enough to render the web interface you could avoid using the metadata-heavy tag and album views, sticking to the folder view or see how you go with an mpd client app like MPDroid or, as you say, BubbleUPnP which will be quicker purely because they're native apps rather than running in a web browser but they'll be less featureful.
Reply
#3
Vinnn, thanks for the reply.  just to clarify, my browser side hardware has included recent android tablets and a windows desktop, not just a phone.  As for your experience with roughly 8000 albums being manageable, I'm not surprised: I  have no performance problems at this size range.  As I stated, I noticed significant issues around 220,000 tracks.  If you get there, I pretty confidently predict you will see the delays and as you get enough above 220,000 performance will degrade severely.

In addition to the repository size, my experience trying different hardware on the server and client sides does show additional hardware ameliorates, but does not eliminate, the slowness.  I found bubbleupnp has no performance problem and is more useful than mpdroid, but I'd love to have the moode interface and functionality.  Over time, more users will evolve into a regime where performance is an issue.  I haven't gotten quantitative, but bubble is responding to a touch in a time that feels like under 40 ms, and moode is sometimes taking seconds.  Thats quite a difference.
Reply
#4
Thanks for the suggestions. Since bubble is using the same music repository, music server, client machine and network as moode, NAS and network issues seem very unlikely. I have used clients mostly wireless, but I have used wired clients as you suggest, such as my windows 10 box, with little appreciable improvement. I've been at pains to point out that bubble is using the same clients, same network, same NAS repository, same moode install on same pi, and yet is 1-2 orders of magnitude faster than moode on some operations. I think this shows looking more at the network or NAS is not likely to be productive. I may eventually create a local USB repository as you suggest, but don't expect that to rectify this performance. Note that the degradation appears strongly correlated to index size: the system performs great with a small repository.

I hope this isn't sounding too negative. moode is one of the finest software products I've used for any application. I have tried a very large number of music systems over nearly 20 years, and moode is arguably the best. I think I've identified a scaling issue, not a network or fileserver problem.....
Reply
#5
The Library Tag and Album views load the entire collection as a tag-cache array into the Browsers memory. This works well for the majority of users and provides easy and fat navigation but it does not scale for extremely large collections.

The Tag and Album views could be redesigned and coded to be purely on-demand, query based which would scale nicely but its a non-trivial effort and would require an additional dev to do the work.

-Tim
Reply
#6
ok, thanks tim, this is about what I expected...
As you say, this would require development, almost redesign to provide incremental data to the client, and would only benefit a few of us. I've documented the issue, and perhaps I can lobby slightly by pointing out that as digital music matures, this scaling problem will be gradually affecting more users.

Thanks again for a terrific piece of software...
Reply
#7
I have problem with performance too. I stop asking for help, it useless. I move to Volumio for now. Maby in future Moode will be better optimized.
Reply
#8
I have the same problem described by @soundof-ferns.
But I have not suffered from this issue in moode 6.3. (Actually I have downgraded to 6.3 and this problem has gone away.)
So I am definitely sure that this issue is a bug in moode 6.4 and it can be fixed.
Reply
#9
(01-16-2020, 01:58 AM)Sungsoo Kim Wrote: I have the same problem described by @soundof-ferns.
But I have not suffered from this issue in moode 6.3. (Actually I have downgraded to 6.3 and this problem has gone away.)
So I am definitely sure that this issue is a bug in moode 6.4 and it can be fixed.

More data please. How large is your library and where are you noticing slowness? Can you capture the console log? I forget when the new library code hit, if it was 6.4 then that might explain a regression but it’s been very responsive with my ~25000 track collection though that’s just a small fraction of what the original poster had.

Moode’s webui has the same limitations as any other website and extremely large lists are a major pain point for browsers. The more complex the list (and thus page) the more memory it uses and the harder your device has to work to display it. Turning off any eye candy (backdrops, alpha blend, etc.) helps as that means less compositing. The tag view with album covers is much more demanding than without, there’s a hidden toggle in the playerlib.js file that disables them. I looked a bit into libraries that allow loading large lists in sections but not having all the data in memory means moode can’t do some of the things it does now so it seemed like a non-starter (and it still wouldn’t ever be as fast or efficient as native code whether it’s bubbleupnp or glider or whatever) so right now the answer for extremely large libraries is the same as the op found. If you have a ~50k item library (or less) and are noticing major ui lag then pm me.
Reply
#10
(01-17-2020, 07:52 AM)swizzle Wrote: More data please. How large is your library and where are you noticing slowness? Can you capture the console log? I forget when the new library code hit, if it was 6.4 then that might explain a regression but it’s been very responsive with my ~25000 track collection though that’s just a small fraction of what the original poster had.
...

I have tested with a library sized 166,806 tracks. (And my client hardware is Macbook pro 2018 with 16 GB RAM, 1 TB SSD, so this does not result from the slow hardware.)

When I touch the top bar on the playback screen, it slides down after 5 seconds or more. (This is exactly the same symptom described by @soundof-ferns) This problem always occurs in moode 6.4, but not at all in moode 6.3. So I think there is a bug in moode 6.4 related to this problem.
Reply


Forum Jump: