Youtube Music Desktop API has changed

[LazerFX]

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

What happened?

I installed YouTube Music Desktop and expected to be able to enable the "ytm" endpoint. Sadly, this did not appear. It looks like some time late in 2023, there was a new version of the API - documented here - which does not support the /query endpoint that was previously used.

The endpoint now requires authorisation, with a key/prompt/response process (App sends a key, YTM displays a prompt, returns a token for future use).

I will attempt, when I have time, to build some integration into this myself, but I wanted an issue on the board in-case someone else was aware of this.

Theme

My own

What OS are you seeing the problem on?

Windows

Which shell are you using?

powershell

Log output

Print the prompt in debug mode.

Usage:
  oh-my-posh prompt debug [bash|zsh|fish|powershell|pwsh|cmd|nu|tcsh|elvish|xonsh] [flags]

Flags:
  -h, --help           help for debug
  -p, --plain          plain text output (no ANSI)
      --pwd string     current working directory
      --shell string   the shell to print for

Global Flags:
  -c, --config string   config file path

[LazerFX]

An example .http request/response transaction for the new flow is this:

# @name requestCode
POST http://127.0.0.1:9863/api/v1/auth/requestcode
Content-Type: application/json

{
    "appId": "ohmyposh",
    "appName": "Oh-My-Posh",
    "appVersion": "0.0.1"
}

###
# @name request
POST http://127.0.0.1:9863/api/v1/auth/request
Content-Type: application/json

{
    "appId": "ohmyposh",
    "code": "{{requestCode.response.body.code}}"
}

###
GET http://127.0.0.1:9863/api/v1/state
Accept: application/json
Authorization: {{request.response.body.token}}

This is in .http format, as per the humao.rest-client / Rest Client plugin for VS Code.

There is user interaction to approve as part of this flow.

1. The YTMD app needs to be in 'Enable Companion Authorization' mode (Settings -> Integrations -> Enable Companion Authorization).
2. The request goes through, and when the /auth/request call is made, the YTMD pops a dialogue asking if you want to grant Oh-My-Posh access. This times out after 30 seconds, so should likely be an asynch process. This will display the one-time-code from the first request.
3. Once approved, the token then should be stored and is maintained.

The state response is now far more complex as well - it gives the full playlist. To find the currently playing track, you need to reference

{ 
    "player": { 
        "videoProgress": nn.nnnn   // video/song progress in seconds
         "queue": { 
            "items": [ { 
                "selected": true,
                "title": "[Trackname]",
                "duration": "m:ss"  // length, in text format
            } ]
        }
    }
}

To add to the complexity, there's also a rate-limit of once per 5 seconds, with a recommended state getter via Socket.IO...

[LazerFX]

I'm continuing to poke at this in my spare time - I think I might be able to build up a test suite similar to that provided for the lastfrm_test.go file, however I'm not a Go developer so I don't know that I'm using best practices. If I put something forward, would someone else mind analysing it and massaging it into more go-like structure? I don't know what I don't know having never touched it before.

[JanDeDobbeleer]

I don't mind. This is on my list somewhere in September anyways. But beware as #5414 might affect this due to changes in how we cache things. So, only focus on getting it working and ignore the caching inside the segment as that will be removed anyways.

[pjmagee]

ahh, this is why i couldn't get the segment working from the docs!