SanderMertens
[Feature Request]: Api Server - Next Song
Preflight Checklist
- [x] I use the latest version of YouTube Music (Application).
- [x] I have searched the issue tracker for a feature request that matches the one I want to file, without success.
Problem Description
I am Integrating YT_music with Resonite: Displaying current song info inside of the Platform and Playing the Song in a Session synched with Playback Position in the Desktop App. For the Playback inside of a session i automatically put YT Link into a In World Video Player and Sync the Playback Position to all other Users.
Sadly loading YT Videos in Resonite Takes a few seconds longer than in the YT Music App which causes the Start of the Song to cut off.
I would like to be able to preload the nex song comming up to minimize this issue.
i know that i could use the output from /api/v1/queue by looking at "selected": true, but parsing all the data in /api/v1/queue trough the visual coding Language in Resonite is a pain (well JSON parsing is a pain in general)
Proposed Solution
adding a Api endpoint that returns the next song in the current queue. maybe even better would be if one could specify a relative Index to the current playing song (ie: -1= previous song, +1 = next song and so on) Idealy this would return moast of the information that /api/v1/song provides. (without "is-paused" and "elapsed-seconds")
Alternatives Considered
Manually parsing /api/v1/queue and generating the queue as slots in resonite to manually get this information
Additional Information
Visual of the integration Manager with all the Data and controls at the bottom and at the top a video Player that gets the currently playing Song Url and elapsed Seconds
The reason YTMD returns the queue data "as-is" is that YTM's queue behavior keeps changing unpredictably. The data structure might suddenly change one day, or the behavior may differ across user accounts due to A/B testing. Therefore, to make maintenance easier, we decided to return the queue data as-is.
The reason YTMD returns the queue data "as-is" is that YTM's queue behavior keeps changing unpredictably. The data structure might suddenly change one day, or the behavior may differ across user accounts due to A/B testing. Therefore, to make maintenance easier, we decided to return the queue data as-is.
However, this decision does not mean that we won't implement the API you suggested. (We are reviewing the suggestion positively)
Hi, I've submitted a PR for this: #4117
The endpoint is now available at /api/v1/queue/next and should solve the preloading issue.
