[SOLVED] Large library - performance (5.3 VS 4.4)

[Pieter]

Hi @Pieter,

If possible can you test with a fresh moOde 5.3 image?

Thanks,
-Tim

@Tim Curtis

Just tested around a bit on a spare 3B+ with a hard drive connected through USB. The only modifications I did from the base image is setting up WiFi to SSH in. With an empty library performance is zippy; after having run the MPD database scan performance is very similar to the 3B+ I use as my actual moOde device. When I check system activity through htop the cores are running either at single digits or in the low teens.


That said, what does seem to make a huge difference on perceived performance is the browser used. On my iOS devices moOde is a joy to use with smooth scrolling, but on my ageing MBP (mid 2010) scrolling is choppy. I assume that's got to do with hardware acceleration on the client side?

[TookaFace]

Maybe something interessant i forgot to tell.

At first, the scrolling in Albums By Artists view was quite horrible in 5.3 with 10000 titles (no problems with smaller library), like very slow, very laggy with Chrome on Windows, unusable.

I find out it was overlay scrollbars feature causing that. When i disabled the feature in Chrome, scrolling became normal again (doesn't fix other issues unfortunately).

And with 4.4, overlay scrollbars and same library no problems.

[TheOldPresbyope]

I'll wait for Tim's modified JavaScript files before commenting further on lagginess.

As for my puzzler, I find that it's easy to repo on my laptop by changing the browser size to approximate my 9-in tablets in portrait mode. 

When I click back and forth between Radio and Album-by-Artist views, even if it works the first time I soon reach a condition where I can't get to Radio from Album-by-Artist. Then the mouse cursor gives away the game: it fails to change from the pointer arrow to the selector hand when i hover over the Radio (microphone) icon. 

The puzzler seems to be sensitive only to the size/aspect ratio of the browser window. I've been able to trigger it on my laptop with Chrome, Firefox, and Opera.

Regards,
Kent

[swizzle]

I'll wait for Tim's modified JavaScript files before commenting further on lagginess.

As for my puzzler, I find that it's easy to repo on my laptop by changing the browser size to approximate my 9-in tablets in portrait mode. 

When I click back and forth between Radio and Album-by-Artist views, even if it works the first time I soon reach a condition where I can't get to Radio from Album-by-Artist. Then the mouse cursor gives away the game: it fails to change from the pointer arrow to the selector hand when i hover over the Radio (microphone) icon. 

The puzzler seems to be sensitive only to the size/aspect ratio of the browser window. I've been able to trigger it on my laptop with Chrome, Firefox, and Opera.

Regards,
Kent

What was the resolution that triggered this? Different resolutions can have slightly different css profiles and large screen portrait isn’t a common use case so wouldn’t have seen much testing.

One thing that may be causing this is the width of the covers view search field. On the mobile screens we make it smaller so it doesn’t overlap the button bar, it’s possible the resolution of your narrowed window suffers a similar fate. The quick way to test would be to switch to the folders view first, if you can then switch to the radio folder then it’s likely the search field situation.

Unfortunately I don’t think I can test moode with overlay scrollbars as they’re not offered in the Mac version of Chrome, but that report sounds really interesting.

[Tim Curtis]

Here are the lazyload patches :-)

Code:

wget http://moodeaudio.org/test/lazyload-update.zip
unzip -q ./lazyload-update.zip
sudo mv ./playerlib.js /var/www/js
sudo mv ./scripts-panels.js /var/www/js
sudo rm ./lazyload*

-Tim

[TookaFace]

I don't have much time, but i already can say it's wayyyyyy better with the fix, thank you Tim and all the persons concerned

I can't make comparison with 4.4 right now, but it's responsive, no more freezes.

[TheOldPresbyope]

I'll wait for Tim's modified JavaScript files before commenting further on lagginess.

As for my puzzler, I find that it's easy to repo on my laptop by changing the browser size to approximate my 9-in tablets in portrait mode. 

When I click back and forth between Radio and Album-by-Artist views, even if it works the first time I soon reach a condition where I can't get to Radio from Album-by-Artist. Then the mouse cursor gives away the game: it fails to change from the pointer arrow to the selector hand when i hover over the Radio (microphone) icon. 

The puzzler seems to be sensitive only to the size/aspect ratio of the browser window. I've been able to trigger it on my laptop with Chrome, Firefox, and Opera.

Regards,
Kent

What was the resolution that triggered this? Different resolutions can have slightly different css profiles and large screen portrait isn’t a common use case so wouldn’t have seen much testing.

One thing that may be causing this is the width of the covers view search field. On the mobile screens we make it smaller so it doesn’t overlap the button bar, it’s possible the resolution of your narrowed window suffers a similar fate. The quick way to test would be to switch to the folders view first, if you can then switch to the radio folder then it’s likely the search field situation.

Unfortunately I don’t think I can test moode with overlay scrollbars as they’re not offered in the Mac version of Chrome, but that report sounds really interesting.

<Sorry, I've been off at a funeral for a longtime friend and colleague. Growing old isn't for sissies.>

I'm seeing this with my Apple iPad 9.7 (2017) and my Google Nexus 9. In portrait mode, both Safari (on the iPad) and Chrome (on both) are reported to have an inner browser width of 768. Different websites report slightly different heights but in the range of 856-912 depending on browser and tablet. I haven't tried scrounging the .css files to see what the breakpoints are.

I have to disagree about large screen portrait not being a common use case. It's natural for me to hold these tablets in portrait mode in one hand 'cuz that's how I read books and other material.

I absolutely agree this is probably due to the search field. I was just starting to play with that when I had to leave for the service. If you'll recall, I had reported exactly the phenomenon of being able switch to folders view first and then to radio.

Regards,
Kent

[Tim Curtis]

I think its the div below. It has a width setting of 40%. When the width of the UI is less than X then the div starts clipping the left most button which is Radio view.

<div class="btnlist btnlist-top btnlist-top-lib">

We could reduce its width to 35% but there is probably a more intelligent way to calculate the correct width. This is one for @swizzle :-)

[swizzle]

We’d have to use javascript to measure the element, 35% is prob fine. We could set the z-index to float the button bar over the top but we still wouldn’t want the collision.

[Tim Curtis]

Ya I think 35% will wor.k