Describe the feature you'd like
it would be great to have an option to change the maximum number of items displayed per page, actual limit is 100.
Additional context
I know it was possible with emby by modifying LibraryBrowser.js file, but can't find it in Jellyfin docker container on my Synology Nas.
Thank you for pointing that out to me. I use Jellyfin on a Synology in a Docker container and can't find the movies.js and tvshows.js in the volume /path/to/config:/config folder, so I suppose it's inside the container? Sorry for the dumb question but I'm new to Docker.
@poulpor I actually have not used the Docker version myself, but that sounds like it makes sense. All those files would be inside the container, because it's not part of the "user" settings or configuration.
Thank you for your help, I've installed vim editor in the container, thanks to Synology Docker app terminal ("apt-get update" then "apt-get -y install vim"), after that, was able to modify pageSize = 100 in tvshows.js and movies.js to desired value.
But because it's a bit complicated for Docker users, I would still love to see a simple option in jellybin settings :)
The problem with making this a higher number is that it makes the interface slow as hell and loading anything takes forever too. It's rather obvious that it wasn't mean't for anything higher than 100 items.
Eventually I think we'll get to the point of lazy loading (like Plex does). There are already some speed improvements with Kestrel in the upcoming release.
I don't have a lot more than 100 items and didn't notice slowdowns since I changed this value to 200, but I don't doubt it would be a lot different with more than 500 items to display.
Glad to hear Kestrel will make jellyfin snappier!
Moving to web, so adding this here as a reference - You can optionally adjust by editing a file right now, but making it configurable is the future:
https://www.reddit.com/r/jellyfin/comments/autbcf/feature_request_show_all_items_in_library_on_one/ehamy9l/
I'd like to tackle this as a first issue/feature since I'm new to the Jellyfin party. Looking to implement it as a infinite/lazy scroller. I can see a couple ways to tackle this:
<div> gets "looped" to the other end of the scroller and filled with the new content. Item metadata would get loaded ~50+ at a time so titles can be filled right away and only images need to be fetched on scroll. This uses less memory, only using enough <div>s to fill the screen plus a threshold/spill area, but will be harder to implement (but maybe a better solution?), requiring (as far as I can tell) most of the emby-itemscontainer component to be re-written.Ideally, the server API would return an OffsetIndex or StartIndex field with /Item? queries, to make it easier to track received metadata and avoid race conditions when scrolling fast, so I think I'll make a PR for that in the server repo first.
Since much of emby-itemscontainer component will need re-writing to accomplish this either way, and probably many of the implementations will also need some tweaks, would it be better just to create a new component (i.e. infiniteitemscontainer)?
I personally prefer paginated view (it survives refreshing), but can see a benefit of "infinite scroll" done Plex-y way.
I'd like to give this a look. Is there a spec with the current HTTP API that Jellyfin exposes for the clients to use?
I don't believe we have a current API documentation, so looking into the code is likely your best bet.
I can give you more information as to where to look at the current implementation tonight (GMT+1)
This will be a headache with the current library controllers. Those are actually one of the first things I want to figure out when we migrate to a framework, our current tabs solution is horrendously difficult to work with.
This will be a headache
Yeah that's what I figured
when we migrate to a framework
Are there any concrete plans on what we're going to use?
@KristupasSavickas #889
This will be a headache with the current library controllers.
Turns out it's easier than expected, but there are multiple places to edit due to this thing being P O E T R Y.
It's also going to be slow on huge libraries because our lazy loader is still trash. But hey, first steps and all that.