Increasing limit of returned results from searches

[bradbeattie]

Changes
In the context of jellyfin/jellyfin#8842, many more than 24 items might be relevant. This PR increases the number of returned results per category to accommodate this (e.g. searching for movies with the tag christmas).

Issues
While this isn't a complete solution to #1752 (which would likely require infinite horizontal scroll), it's a sufficient short-term measure to relieve the pressure some users might feel.

[lecelmakerman]

For non infinite scroll horizontal, I work whit this:
General - Custom CSS

#searchPage .itemsContainer, .vertical-list { display: flex; flex-wrap: wrap; }

[bradbeattie]

Working around the PR approval workflow, I can get the effect of this with the following addition to my Dockerfile:

RUN sed -i 's/,Limit:24,/,Limit:240,/g' /jellyfin/jellyfin-web/search.*.chunk.js

[thornbill]

This is not really a viable solution to the problem imho.

There can be 16 different search queries made when searching to search for different item types which at a worst case would mean that 16 x 240 (3,840) results would need to be rendered on the screen. That is just not feasible. Also I doubt anyone wants to horizontal scroll through 240 results.

What we really need is a "view more" option for each section that goes to a paginated results screen for only that item type.

[bradbeattie]

Agreed that the worst case is near 4000 entries. Realistically though, I doubt anywhere around this number would ever be displayed. That said, I'm wholeheartedly on board with a paginated or infinite scroll approach. But given the lack of progress on #1752, I figured a quick workaround would be worthwhile.

240 might be overkill, but ~50-100 might still prove useful especially in the context of tag searching.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[jellyfin-bot]

This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged.

[fhumayun]

Looking for heroes to resolve this merge conflict 😌

[bradbeattie]

Merge conflict resolved. Adjusted the limit from 24 to 240 to 100 as an attempt to compromise on the blocking disagreement.

[thornbill]

Really I think the search page should be rewritten... firing off so many requests is clearly not working well, so we should make a single request and handle separating them by type client side.

This seems like a fine compromise in the meantime though. 🙂

[bradbeattie]

I'd argue that search should be pushed off to something like https://github.com/meilisearch/meilisearch to help address issues of typo correction, stemming, filtering, etc. But that's a much bigger lift than this change.

Additionally, it looks like the PR approval needs a push to move it through.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
2.3% Duplication