[GH-ISSUE #858] get_playlist ignores limit parameter and always returns max 100 tracks

kerem commented

2026-02-27 23:01:16 +03:00

Owner

Originally created by @Hengen42 on GitHub (Jan 27, 2026).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/858

Checklist

I confirm that I have read the FAQ

Describe the bug

When calling get_playlist() with a large limit value, the API still returns only 100 tracks, even though the playlist contains significantly more items.

The playlist metadata correctly reports the real track count via trackCount, but the tracks array is capped at 100 and does not paginate further.

This makes it impossible to programmatically retrieve large playlists (e.g. 1000+ tracks) using get_playlist() alone.

ytmusicapi version

ytmusicapi 1.11.4

(please adjust if needed)

To Reproduce

Steps to reproduce the behavior:

Call get_playlist() with a playlist containing more than 100 tracks
Provide a large limit value (e.g. 5000)
Compare returned track count with playlist metadata

Example code

from ytmusicapi import YTMusic

ytmusic = YTMusic("oauth.json")

playlist_id = "PLAYLIST_ID"

playlist = ytmusic.get_playlist(playlist_id, limit=5000)

tracks = playlist.get("tracks", [])
shown_count = len(tracks)
real_count = playlist.get("trackCount")

print("Shown tracks:", shown_count)
print("Actual track count:", real_count)

Output

Shown tracks: 100
Actual track count: 1527

Expected behavior

get_playlist() should either:

Respect the limit parameter and fetch all tracks up to that limit using continuations, or
Clearly document that the method is hard-limited to 100 tracks and provide an official alternative for full playlist retrieval.

Additional context

The playlist metadata (trackCount) correctly reports the full size
Continuation tokens appear to exist internally but are not exposed or followed

This limitation breaks automation use cases such as:

Playlist backups
Shuffle / regeneration workflows
Syncing large playlists

If this is a known limitation, clarification or guidance on the recommended approach would be appreciated.

Originally created by @Hengen42 on GitHub (Jan 27, 2026). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/858 ### Checklist - [x] I confirm that I have read the [FAQ](https://ytmusicapi.readthedocs.io/en/stable/faq.html#why-is-ytmusicapi-returning-more-results-than-requested-with-the-limit-parameter) ### Describe the bug When calling `get_playlist()` with a large `limit` value, the API still returns only `100` tracks, even though the playlist contains significantly more items. The playlist metadata correctly reports the real track count via `trackCount`, but the `tracks` array is capped at `100` and does not paginate further. This makes it impossible to programmatically retrieve large playlists (e.g. `1000+ tracks`) using `get_playlist()` alone. ### ytmusicapi version `ytmusicapi 1.11.4` _(please adjust if needed)_ ### To Reproduce Steps to reproduce the behavior: 1. Call `get_playlist()` with a playlist containing more than `100` tracks 2. Provide a large `limit` value (e.g. `5000`) 3. Compare returned track count with playlist metadata ### Example code ```python from ytmusicapi import YTMusic ytmusic = YTMusic("oauth.json") playlist_id = "PLAYLIST_ID" playlist = ytmusic.get_playlist(playlist_id, limit=5000) tracks = playlist.get("tracks", []) shown_count = len(tracks) real_count = playlist.get("trackCount") print("Shown tracks:", shown_count) print("Actual track count:", real_count) ``` ### Output Shown tracks: 100 Actual track count: 1527 ### Expected behavior `get_playlist()` should either: - Respect the `limit` parameter and fetch all tracks up to that limit using continuations, or - Clearly document that the method is hard-limited to `100` tracks and provide an official alternative for full playlist retrieval. ### Additional context - The playlist metadata (`trackCount`) correctly reports the full size - Continuation tokens appear to exist internally but are not exposed or followed This limitation breaks automation use cases such as: - Playlist backups - Shuffle / regeneration workflows - Syncing large playlists If this is a known limitation, clarification or guidance on the recommended approach would be appreciated.

kerem

2026-02-27 23:01:16 +03:00

closed this issue
added the
bug

invalid
labels

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@kipavy commented on GitHub (Jan 27, 2026):

I have also encountered this issue, the following code shows 100 tracks but the real playlist has 154 tracks

from ytmusicapi import YTMusic
c = YTMusic()
p = c.get_playlist("OLAK5uy_k1JNTGqS37d2tB4SvtJ_xd9Bj3MSlGCjo", limit=None)
print(f"Track Count: {p['trackCount']}")

@kipavy commented on GitHub (Jan 27, 2026): I have also encountered this issue, the following code shows 100 tracks but [the real playlist](https://music.youtube.com/playlist?list=OLAK5uy_k1JNTGqS37d2tB4SvtJ_xd9Bj3MSlGCjo) has 154 tracks ```python from ytmusicapi import YTMusic c = YTMusic() p = c.get_playlist("OLAK5uy_k1JNTGqS37d2tB4SvtJ_xd9Bj3MSlGCjo", limit=None) print(f"Track Count: {p['trackCount']}") ```

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@sgvictorino commented on GitHub (Jan 28, 2026):

@Hengen42 does this only happen when you're authed? Is the playlist private?

@sgvictorino commented on GitHub (Jan 28, 2026): @Hengen42 does this only happen when you're authed? Is the playlist private?

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@kipavy commented on GitHub (Jan 28, 2026):

@Hengen42 does this only happen when you're authed? Is the playlist private?

It happened to me without being logged in, on a public playlist

@kipavy commented on GitHub (Jan 28, 2026): > [@Hengen42](https://github.com/Hengen42) does this only happen when you're authed? Is the playlist private? It happened to me without being logged in, on a public playlist

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@sgvictorino commented on GitHub (Jan 28, 2026):

@kipavy your issue should be fixed by #860

@sgvictorino commented on GitHub (Jan 28, 2026): @kipavy your issue should be fixed by #860

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@kipavy commented on GitHub (Jan 28, 2026):

@kipavy your issue should be fixed by #860

Thank you a lot, I hope ytmusicapi releases a hotfix soon on PyPi

@kipavy commented on GitHub (Jan 28, 2026): > [@kipavy](https://github.com/kipavy) your issue should be fixed by [#860](https://github.com/sigma67/ytmusicapi/pull/860) Thank you a lot, I hope ytmusicapi releases a hotfix soon on PyPi

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@Hengen42 commented on GitHub (Jan 31, 2026):

Problem description

The issue still persists.

The important point here is not the ability to see the total track count — that part already works and can be obtained from the playlist metadata.

The real problem is that there is no way to retrieve the full track data as JSON for playlists larger than 100 items.
No matter what approach is used, the API always returns only the first 100 tracks, and there is currently no supported way to access the remaining tracks programmatically.

In other words, while the playlist may contain hundreds or even thousands of tracks, it is impossible to fetch all track objects (titles, artists, video IDs, etc.) as a complete JSON list. The limitation is always hard-capped at 100 items.

This means the core issue is data access, not track counting — and this issue has still not been resolved.

from ytmusicapi import YTMusic

ytmusic = YTMusic("oauth.json")

playlist_id = "PLAYLIST_ID"

playlist = ytmusic.get_playlist(playlist_id)

tracks = playlist['tracks'] # Çalma listesindeki şarkıları alın
#print(tracks)
total_tracks = len(tracks) # playlistin içindeki toplam şarkı sayısını alma
print(total_tracks)

Explanation of the problem

len(tracks) always returns 100
This happens regardless of the actual playlist size
The playlist metadata correctly reports the full track count
However, there is no way to retrieve all tracks as JSON
The tracks field is permanently limited to 100 items

If you print the `#print(tracks)` line in the code as a normal statement instead of a comment, you will see that it still returns JSON data for only 100 tracks; this is where I want to point out that the actual issue lies.

@Hengen42 commented on GitHub (Jan 31, 2026): Problem description The issue still persists. The important point here is not the ability to see the total track count — that part already works and can be obtained from the playlist metadata. The real problem is that there is no way to retrieve the full track data as JSON for playlists larger than 100 items. No matter what approach is used, the API always returns only the first 100 tracks, and there is currently no supported way to access the remaining tracks programmatically. In other words, while the playlist may contain hundreds or even thousands of tracks, it is impossible to fetch all track objects (titles, artists, video IDs, etc.) as a complete JSON list. The limitation is always hard-capped at 100 items. This means the core issue is data access, not track counting — and this issue has still not been resolved. ``` from ytmusicapi import YTMusic ytmusic = YTMusic("oauth.json") playlist_id = "PLAYLIST_ID" playlist = ytmusic.get_playlist(playlist_id) tracks = playlist['tracks'] # Çalma listesindeki şarkıları alın #print(tracks) total_tracks = len(tracks) # playlistin içindeki toplam şarkı sayısını alma print(total_tracks) ``` ### Explanation of the problem - len(tracks) always returns 100 - This happens regardless of the actual playlist size - The playlist metadata correctly reports the full track count - However, there is no way to retrieve all tracks as JSON - The tracks field is permanently limited to 100 items ### **If you print the `#print(tracks)` line in the code as a normal statement instead of a comment, you will see that it still returns JSON data for only 100 tracks; this is where I want to point out that the actual issue lies.**

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@sigma67 commented on GitHub (Jan 31, 2026):

Yeah sorry guys, I tried

OLAK5uy_k1JNTGqS37d2tB4SvtJ_xd9Bj3MSlGCjo

provided by @kipavy and it's giving me back exactly 154 tracks.

Unfortunately OP did not provide any playlists for reproduction. So I'm going to mark this as invalid, unless you can provide more concrete instructions for reproduction.

And besides, we have plenty of tests testing with more than 100 limit tracks, so unless it's something specific to your account or playlist we would have seen it a long time ago if it was a general issue.

@sigma67 commented on GitHub (Jan 31, 2026): Yeah sorry guys, I tried - OLAK5uy_k1JNTGqS37d2tB4SvtJ_xd9Bj3MSlGCjo provided by @kipavy and it's giving me back exactly 154 tracks. Unfortunately OP did not provide any playlists for reproduction. So I'm going to mark this as invalid, unless you can provide more concrete instructions for reproduction. And besides, we have plenty of tests testing with more than 100 limit tracks, so unless it's something specific to your account or playlist we would have seen it a long time ago if it was a general issue.

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@Hengen42 commented on GitHub (Feb 4, 2026):

Yes, I want to state that I have solved the issue and provide feedback. In the problematic playlist, under the “Edit list” section, the “Voting” option must definitely be set to “Closed.” In the photo below, I showed where it needs to be corrected:

Also, as proof: the screenshot I obtained when my automatic backup program ran the day after changing only that setting:

@kipavy my friend, could you try it and let me know whether it’s resolved or not?

@Hengen42 commented on GitHub (Feb 4, 2026): Yes, I want to state that I have solved the issue and provide feedback. In the problematic playlist, under the “Edit list” section, the “Voting” option must definitely be set to “Closed.” In the photo below, I showed where it needs to be corrected: <img width="402" height="432" alt="Image" src="https://github.com/user-attachments/assets/d3cf5a8f-98bc-4aef-8dd3-b7de28d437e7" /> Also, as proof: the screenshot I obtained when my automatic backup program ran the day after changing only that setting: <img width="1814" height="152" alt="Image" src="https://github.com/user-attachments/assets/320980c1-0cb0-4b32-a4b5-fe529377f1d7" /> @kipavy my friend, could you try it and let me know whether it’s resolved or not?

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@sgvictorino commented on GitHub (Feb 4, 2026):

@Hengen42 thanks for troubleshooting this. I can tweak the parser so we return all the tracks when voting is enabled.

@sgvictorino commented on GitHub (Feb 4, 2026): @Hengen42 thanks for troubleshooting this. I can tweak the parser so we return all the tracks when voting is enabled.

kerem commented

2026-02-27 23:01:16 +03:00

Author

Owner

@sigma67 commented on GitHub (Feb 5, 2026):

That option seems new - we should create a separate issue to track it.

@sigma67 commented on GitHub (Feb 5, 2026): That option seems new - we should create a separate issue to track it.

Rows
Columns

[GH-ISSUE #858] get_playlist ignores limit parameter and always returns max 100 tracks #525

Checklist

Describe the bug

ytmusicapi version

To Reproduce

Example code

Output

Expected behavior

Additional context

Explanation of the problem

If you print the #print(tracks) line in the code as a normal statement instead of a comment, you will see that it still returns JSON data for only 100 tracks; this is where I want to point out that the actual issue lies.

If you print the `#print(tracks)` line in the code as a normal statement instead of a comment, you will see that it still returns JSON data for only 100 tracks; this is where I want to point out that the actual issue lies.