[GH-ISSUE #509] Return actual track positions #371

New issue

Closed

opened 2026-02-27 23:00:26 +03:00 by kerem · 0 comments

kerem commented

2026-02-27 23:00:26 +03:00

Owner

Originally created by @jcbirdwell on GitHub (Jan 9, 2024).
Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/509

Is your feature request related to a problem? Please describe.
Occasionally some albums will appear on YouTube music with tracks completely missing (not just unavailable). In these cases using the index of the returned track list is insufficient for positioning all tracks. The correct indexing for these tracks is still maintained on YouTube, but the value isn't parsed from the response.

Describe the solution you'd like
Add the track_position key to songs parsed in parse_playlist_items and its corresponding lookup path to the response value.

Describe alternatives you've considered

Ignore it (never).
Separate method for pulling true indexes (seems silly when the value is already there)
The path to a song's index in the response is similar to other keys (duration) and provides potential for refactoring out something similar to navigation.nav for extracting these values. I left it as a basic index lookup for now (similar to nearby stuff) as I'm currently unfamiliar with the labyrinth of parsing code and didn't want to dig into it.

Additional context
The album that originally threw the error in my code while using native indexing (browseId: MPREb_TPH4WqN5pUo) https://music.youtube.com/playlist?list=OLAK5uy_n7Xde1CFVX7Y8PeyGiAc2V4ieTRs3PML8

It seems to be a exceedingly rare occurrence.

Originally created by @jcbirdwell on GitHub (Jan 9, 2024). Original GitHub issue: https://github.com/sigma67/ytmusicapi/issues/509 **Is your feature request related to a problem? Please describe.** Occasionally some albums will appear on YouTube music with tracks completely missing (not just unavailable). In these cases using the index of the returned track list is insufficient for positioning all tracks. The correct indexing for these tracks is still maintained on YouTube, but the value isn't parsed from the response. **Describe the solution you'd like** Add the track_position key to songs parsed in parse_playlist_items and its corresponding lookup path to the response value. **Describe alternatives you've considered** 1. Ignore it (never). 2. Separate method for pulling true indexes (seems silly when the value is already there) 3. The path to a song's index in the response is similar to other keys (duration) and provides potential for refactoring out something similar to navigation.nav for extracting these values. I left it as a basic index lookup for now (similar to nearby stuff) as I'm currently unfamiliar with the labyrinth of parsing code and didn't want to dig into it. **Additional context** The album that originally threw the error in my code while using native indexing (browseId: MPREb_TPH4WqN5pUo) https://music.youtube.com/playlist?list=OLAK5uy_n7Xde1CFVX7Y8PeyGiAc2V4ieTRs3PML8 It seems to be a exceedingly rare occurrence.