Navidrome: Add option for "infinite" scrolling trough Artists, albums, genres ect

[antipiot]

Hey!
I would like to be able, if possible, to infinite scroll trough artists, albums, genres ect without having to click on "next" to see more.

Additionnaly, if you select to show like 50 artists, the playbar at the bottom mask the next button. Is this done on purpose? i know you can reduce it but, you know, less click is always better :-)

Thanks once again for your work!

[deluan]

I'd love to have it, but I can't find a way to do this with ReactAdmin, the framework used for the UI.

Re: player blocking the pagination, I'll work on a fix for it.

[deluan]

Maybe we can borrow some ideas from this blog post: https://marmelab.com/blog/2019/01/17/react-timeline.html

[antipiot]

I'd like to help you but i have absolutely no knowledge about this :-/

[deluan]

@antipiot I pushed a fix for the "player blocking the pagination" issue

[antipiot]

@antipiot I pushed a fix for the "player blocking the pagination" issue

Good job!
Waiting for it to be pushed on the docker :-)

[deluan]

I still have work to do on the Album grid view before releasing a new version. Meanwhile if you want, you may use the develop docker image, tag: deluan/navidrome:develop

[antipiot]

Ho! did not thinked about that! Will do in not time.
Is there a way to send you a beer for your work? Navidrome looks really promising to me, and i've tested everything i could :-)

Airsonic is getting a bit old and navidrome have better handling of albums with more than 1 CD
Funkwhale looks really great but you need 2 login for the Subsonic API
koel looks great, but no subsonic API wich is a real minus

[certuna]

I'd love this, but how big is the impact on memory usage, eg with a list of 100,000 songs or 20,000 artists?

[jvoisin]

I don't think that anyone has 20,000 artists.

Moreover, the majority of the other subsonic servers are doing it, and they don't make the browser crash.

[certuna]

I don't think that anyone has 20,000 artists.

_[sheepishly raises hand]_ I do...

(but yes I think that on modern systems a browser should be able to handle an HTML table of 20,000 lines)

[antipiot]

I'm not used to this, but i guess infinite scrolling will only load what's need to be displayed:
it wont load everything - as a video game dont load every level in memory, it only render what the player is looking at :-)

[antipiot]

@deluan , i have a feeling this may help:
https://github.com/CassetteRocks/react-infinite-scroller

[legobuild]

I realize infinite scrolling might be a ways off, but could you add a higher option for number of items displayed (15/50/100/500)? Also, could that be a setting that gets saved so the user doesn't need to increase it at each logon?

[deluan]

We can definitely add more perPage options. Will add them for next release

Did not add this options as increasing the number of rows beyond 50 is slowing down the grid rendering. The infinite scroll would be better in this case, as it would add 20 new rows each time you reach the bottom, but would not re-render everything in the page.

[esiqveland]

The getArtists call works fine for this in my opionion, you would have to have huge number of artists for that to become unfeasible. However I notice most of the artists in the listing are missing cover art. Would that be much trouble to add?

[deluan]

The UI does not use the Subsonic API to browse music, so getArtists is not used by it (and this call is actually not paginated). About having too many artists, my library has 1180, which is already a lot for the UI to render, and I know of some users that have as much as 11440 artists! So, not paginating artists is unfeasible until we have infinite scroll.

As for the cover art, Navidrome mimics Subsonic's behaviour: It only get the artist image when there's a call to getArtistInfo, which is used to show an artist page in Subsonic clients. Once that call is made, the artist art is cached and served in other calls. This may change in the future, I want to add a worker pool to get this info in background as new artists are added to the library.

[esiqveland]

The UI does not need to render all artists at once, only the ones that are currently visible. As long as the response is small enough (in MB) that the client can parse it in a reasonable amount of time, there is no issue to make this at least scrollable. Some mobile clients may experience issues with as many as 11440 artists though, because the payload becomes quite big! Having all the data available also makes it simpler to deal with layouts, as any constraints can be known.

A cached, preloaded artist artwork would be amazing, especially if a a link can be included in the response.