Announcements

Help Wizard

Step 1

NEXT STEP

Cannot Transfer Playback - Descriptor ID?

Cannot Transfer Playback - Descriptor ID?

Plan: Premium

Country: United States

Device: Macbook Pro

Operating System: Mojave

Browser: Chrome

 

My Question or Issue

I cannot transfer playback to my web app. This used to work just fine, but is throwing a new error I haven't seen before. I'm able to create the player, successfully connect to Spotify, and get a device ID. I can see it as expected when I call GET /devices.

 

When I call PUT on "/me/player" to transfer the playback (with the device ID in the body array "device_ids"), I get a 202 success status. 

 

In the console of my browser, I see this: 

"Uncaught CloudPlaybackClientError: Descriptor ID is null"

I cannot find any documentation on that error, or what playback_descriptor_id is. 

 

If I try to play anything after that, I get a 404 and "Player command failed: No active device found".

Reply
8 Replies

Hi @rhen321, welcome to the developer forum!

Thanks for bringing this up, I have not seen this particular error before. Are you seeing this problem with all types of content, or with a particular song, podcast or episode? 

Yes, all types of content are unplayable, since the Transfer User Playback PUT did not actually transfer playback. The device is not "active" if I call get all devices, even after a successful PUT. What is the Descriptor ID the error message is asking for? 

 

I have a hobby web app that I've already launched with this and it has worked wonderfully for a year, but now it's broken (no changes on my end) and I'm desperate to get it back to functional. 

@spotifyjosh is there any update here? I've contacted the support team three times and done my best to dig into this error, I have no idea how to fix it. This is broken on a live project for me and affecting hundreds of users. 

Hey rhen321,

 

Since I couldn't reproduce the issue, allow me to share with you the steps I followed in case it helps. For the test, I have used Chrome 99.0.4844.51 and Web Playback SDK v1.9.0-bb5ba1b. 

 

I started by creating a new Web Playback SDK instance (note that this instance does not receive the playback automatically). Then, I do a GET to /me/player/devices to see if the instance has been correctly registered. The response looks similar to this:

 

{
  "devices": [
    {
      "id": "9912c96a1c1fd14247ab06708239d38f41a2181f",
      "is_active": false,
      "is_private_session": false,
      "is_restricted": false,
      "name": "Web Playback SDK",
      "type": "Computer",
      "volume_percent": 49
    },
    {
      "id": "2a34567134e3d0983823d0ad0319b6a14dbe78d1",
      "is_active": true,
      "is_private_session": false,
      "is_restricted": false,
      "name": "MYCOMPUTER",
      "type": "Computer",
      "volume_percent": 70
    }
  ]
}

Finally, I transfer the playback by sending a PUT to /me/player with the following body:

 

 

{
  "device_ids": [
    "9912c96a1c1fd14247ab06708239d38f41a2181f"
  ]
}

 

 

Some questions to consider:

- Could you please check the Web Playback SDK version you are using?

- Did you, by mistake, modify/delete your app (along with the client credentials) in the dashboard?

- Are you getting the same error using a minimal setup? (e.g using the Web Playback SDK example from the Quick Start, and the Console to perform the API calls)

Hi alvaron, by sending method POST to the /me/player will return a 405 error, the only accepted method is PUT, as described in the official documentation. In the past, I've encountered the same problem which the server returns 202 and the playback device is still not activated. By clicking "Try It" button on the official documentation, it somehow works and now my script no longer returns 204, which is odd. Now that I updated in my project settings (I added a new redirect url), the problem came back (returns 202). To make matter worse, as of now (2-June) the "Try It" button is no longer available in the Transfer Playback section of the documentation, which leaves me no room to figure out this issue. Below is the approach I've taken.

fetch("https://api.spotify.com/v1/me/player/devices", {
                        headers: {
                            Authorization: "Bearer " + ACCESS_TOKEN,
                        },
                    }).then((response) =>
                        response.json().then((data) => {
                            console.log(data);
                            fetch("https://api.spotify.com/v1/me/player", {
                                method: "POST",
                                headers: {
                                    Authorization: "Bearer " + ACCESS_TOKEN,
                                    "Content-Type": "application/json",
                                },
                                
                                body: `{
                                "device_ids": [
                                    "${device_id}"
                                ]
                            }`,
                            }).then((response) => console.log(response));
                        })
                    );

(Note that I used Web Playback SDK, thus the device_id variable is used)

I have done the following

- Check available devices first

- Send appropriate fetch request to the appropriate endpoint

- Re-check numerous times on the fetching request

 

As expected, the output of the transfer playback request is

body: (...)
bodyUsed: false
headers: Headers {}
ok: true
redirected: false
status: 202
statusText: ""
type: "cors"
url: "https://api.spotify.com/v1/me/player"

A quick reply would be highly appreciated as this is part of my assignment, and the due date is near.

Thank you.

A minor update, I was worried that it might be my computer that produces this bug, apparently not.

I have tried the the CURL command on the web API documentation both on terminal, and on online CURL tester. Unfortunately, both method produces response status of 202.

 

 

Screenshot 2023-06-02 at 6.11.10 PM.png

Hey! You're right. There is a typo in my previous response. It should be "PUT" instead of "POST". Well spotted, thanks! 

 

I've tried to reproduce the issue with the following fetch call (using scopes: streaming and user-read-playback-state) , but everything seems to work:

const req = { method: 'put',
              headers: { Authorization: "Bearer " + token },
              body: JSON.stringify({ device_ids: ["XXXX"], })
            }
const response = await fetch("https://api.spotify.com/v1/me/player", req);

 

HI alvaron, I dig a little deeper and found out that by transferring to other devices (not Web Playback SDK) seems to be functioning well, I did a little experiment earlier, here's what I found.

 

I used an online cURL tester for references.

First, I opened the official web spotify (open.spotify.com), then I fired up the Web Playback SDK from my project and get both device ID from the /me/player/devices,

I switched to the web spotify by using /me/player endpoint and it seems like everything was okay. It switched out perfectly and are able to play musics.

However, once I switched back to the Web Playback SDK, it returns 202, and again, no music are playing.

Surprisingly, on the official web spotify, it shows that I am currently listening on Web Playback SDK with the music currently paused.

I clicked the play button, even switching to another song on the web spotify while audio were connected to the Playback, it won't play. But it do switches the music. I even tried other methods such as /me/play?device_id=XXX and it runs as expected. 204 on the web spotify and 202 on the Web Playback SDK. I suspect something may happening on the backend-side here.

 

I am frustrated, to say the least, I am even willing to host an online meeting (**bleep**) for you guys to see what could potentially be the problem. I might try to create a new project with new client id to see if this issue still persists.

 

Thank you, alvaron for replying in quick succession. I hope you would still be active to this thread and help us.

Suggested posts