/Items Endpoint for IncludeItemTypes=Playlist doesn't apply limit correctly #7227

New Issue

OVERLORD · 2026-02-07T04:43:38+03:00

OVERLORD commented

2026-02-07 04:43:38 +03:00

Originally created by @Chaphasilor on GitHub (Aug 7, 2025).

Description of the bug

When requesting playlists using the /Items endpoint without providing a parent ID and adding a limit to the request, the returned amount of items will be incorrect if there are private playlists from other user accounts that are filtered out.
Jellyfin will seemingly apply the filter after applying the limit, causing the amount of returned items to be too few.

Reproduction steps

Have two user accounts, A and B.
A makes the requests and B has at least one private playlist, and there should be multiple public playlists on the server. The private playlist must not be the last playlists for default/alphabetical sorting (this last part only matters for the reproduction not the underlying API issue).
Open dev tools. Navigate to a music library (which one doesn't matter), and there to the playlists tab using account A
All playlists are shown, because Jellyfin doesn't apply a limit here by default. Edit the request for playlists to include the limit, which is slightly less than the total amount of playlists (including private ones). Send the request
The amount of returned items will be less than the specified limit

What is the current bug behavior?

Under some specific conditions (at least one private playlist by another user that would be included in the sorting + limit if it were public), the endpoint will return fewer items than requested by the limit

What is the expected correct behavior?

The filtering for private playlists should happen before or alongside applying the limit, to ensure that all user-accessible playlists up until the limit are correctly included.

Jellyfin Server version

Unstable

Specify commit id

No response

Specify unstable release number

10.11

Specify version number

10.10.7 also has this issue

Specify the build version

2025080405

Environment

- OS: TrueNAS Scale, based on Debian
- Linux Kernel:
- Virtualization:
- Clients:
- Browser:
- FFmpeg Version:
- Playback Method:
- Hardware Acceleration:
- GPU Model:
- Plugins:
- Reverse Proxy:
- Base URL:
- Networking:
- Jellyfin Data Storage:
- Media Storage:
- External Integrations:

Jellyfin logs

No relevant logs in the server log file :)

FFmpeg logs

Client / Browser logs

GET <base url>/Items?SortBy=SortName&SortOrder=Ascending&IncludeItemTypes=Playlist&Recursive=true&Fields=PrimaryImageAspectRatio%2CSortName%2CCanDelete&StartIndex=0&Limit=20
--> Returns 19 items, even though 24 user-accessible playlists exist

Relevant screenshots or videos

No response

Additional information

This causes pagination / infinite scroll to break in Finamp on the playlists tab, since we stop trying to fetch more playlists if the returned amount of items is less than the page size.
Yes this could be improved on our side since the TotalRecordCount is correct, but it's still an issue nonetheless :)

Originally created by @Chaphasilor on GitHub (Aug 7, 2025). ### Description of the bug When requesting playlists using the /Items endpoint **without providing a parent ID** and adding a `limit` to the request, the returned amount of items will be incorrect **if there are private playlists from other user accounts that are filtered out**. Jellyfin will seemingly apply the filter *after* applying the limit, causing the amount of returned items to be too few. ### Reproduction steps 1. Have two user accounts, `A` and `B`. `A` makes the requests and `B` has **at least one private playlist**, and there should be multiple public playlists on the server. The private playlist **must not** be the last playlists for default/alphabetical sorting (this last part only matters for the reproduction not the underlying API issue). 2. Open dev tools. Navigate to a music library (which one doesn't matter), and there to the playlists tab using account `A` 3. All playlists are shown, because Jellyfin doesn't apply a limit here by default. Edit the request for playlists to include the limit, which is slightly less than the total amount of playlists (including private ones). Send the request 4. The amount of returned items will be less than the specified limit ### What is the current _bug_ behavior? Under some specific conditions (at least one private playlist by another user that would be included in the sorting + limit if it were public), the endpoint will return fewer items than requested by the limit ### What is the expected _correct_ behavior? The filtering for private playlists should happen **before or alongside** applying the limit, to ensure that **all user-accessible playlists up until the limit are correctly included.** ### Jellyfin Server version Unstable ### Specify commit id _No response_ ### Specify unstable release number 10.11 ### Specify version number 10.10.7 also has this issue ### Specify the build version 2025080405 ### Environment ```markdown - OS: TrueNAS Scale, based on Debian - Linux Kernel: - Virtualization: - Clients: - Browser: - FFmpeg Version: - Playback Method: - Hardware Acceleration: - GPU Model: - Plugins: - Reverse Proxy: - Base URL: - Networking: - Jellyfin Data Storage: - Media Storage: - External Integrations: ``` ### Jellyfin logs ```shell No relevant logs in the server log file :) ``` ### FFmpeg logs ```shell ``` ### Client / Browser logs `GET <base url>/Items?SortBy=SortName&SortOrder=Ascending&IncludeItemTypes=Playlist&Recursive=true&Fields=PrimaryImageAspectRatio%2CSortName%2CCanDelete&StartIndex=0&Limit=20` --> Returns 19 items, even though 24 user-accessible playlists exist ### Relevant screenshots or videos _No response_ ### Additional information This causes pagination / infinite scroll to break in Finamp on the playlists tab, since we stop trying to fetch more playlists if the returned amount of items is less than the page size. Yes this could be improved on our side since the `TotalRecordCount` is correct, but it's still an issue nonetheless :)

OVERLORD added the bug label 2026-02-07 04:43:38 +03:00

OVERLORD commented

2026-02-07 04:43:40 +03:00

@jellyfin-bot commented on GitHub (Dec 6, 2025):

This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs.

If you have any questions you can use one of several ways to contact us.

@jellyfin-bot commented on GitHub (Dec 6, 2025): This issue has gone 120 days without an update and will be closed within 21 days if there is no new activity. To prevent this issue from being closed, please confirm the issue has not already been fixed by providing updated examples or logs. If you have any questions you can use one of several ways to [contact us](https://jellyfin.org/contact).

OVERLORD commented

2026-02-07 04:43:41 +03:00

@Komodo5197 commented on GitHub (Dec 17, 2025):

@Chaphasilor I'm still on 10.10. Does this still happen on 10.11?

@Komodo5197 commented on GitHub (Dec 17, 2025): @Chaphasilor I'm still on 10.10. Does this still happen on 10.11?

OVERLORD referenced this issue

2026-02-07 06:36:08 +03:00

[PR #7227] [CLOSED] Fix h264_v4l2m2m acceleration in Raspberry Pi 4 #11308

OVERLORD referenced this issue

2026-02-07 06:36:38 +03:00

[PR #7291] [MERGED] Fix h264_v4l2m2m acceleration in Raspberry Pi 4 #11334

Sign in to join this conversation.