I've never seen the x-rincon-playlist scheme before, so I'm not sure how that behaves. Usually, (or previously), a call for playing a certain playlist from a music service did the following (this is an example fro spotify):



(optionally, clear queue if replacing)

Invoke AddURIToQueue with the uri for that specific playlist, this will queue all tracks from that playlist

Invoke SetAVTransportURI and set that to x-rincon-queue:[UUID of player]#0



Now, the issue here is that getting a hold of that specific uri is the tricky part, and the controller does it by calling the SMAPI endpoint. This endpoint is authenticated, and the authentication info is an encrypted exchange between the controller and the players. If you would have the actual uri, you could skip this step, but it would then be hardcoded for your user (unless it changes frequently).



For Spotify the uris are easily accessible directly from the Spotify client, but I'm not sure with Amazon. Either way it should be possible to find out by sniffing the traffic between controller and player, because at some point, the controller sends this info to the player (unencrypted).

---

Thank you jishi, always a delight to get your contribution to the discussion.

The getProtocolInfo provides all supported schemas

file:*:audio/mpegurl:*,x-file-cifs:*:*:*,x-rincon:*:*:*,x-rincon-mp3radio:*:*:*,x-rincon-playlist:*:*:*,x-rincon-queue:*:*:*,x-rincon-stream:*:*



that where I got the playlist schema.

I have been successful in leveraging AddURI and SetAV however, I am struggling how to form the URLs in the first place since it appears that there's no SOAP API for that.



I used Wireshark to figure out anything that would have led to a reliable URL to fetch the data from but so far I have failed miserably. It appears that the comms between the player and are not in clear and what is sent to the player it is the aftermath of the call. I can't think of why going to this extra length for something so innocuous as the categories of what you can play.

---