01-01-2020, 07:02 PM
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.
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.
