Fetching audiobooks/podcast metadata results in 502 Bad Gateway

[DamianRyse]

Description

When fetching the metadata of an audio book or a podcast, librespot throws an error "502 Bad Gateway"

Version

librespot-metadata = "0.7.1"

How to reproduce

Show::get(session, &spotify_id)
      .await
      .map_err(|e| Error::new(ErrorKind::Other, format!("Failed to fetch show: {}", e)))

-> Failed to fetch show: Unknown error { Response status code: 502 Bad Gateway }
Tested with the following URIs:

• spotify:show:1IyAJYcVhVN4owCMPNWjSV (Audio book)
• spotify:show:1dQMmMennmPctlQzHDCiZ8 (Audio book)
• spotify:show:3RWaVT0v1SK6iALTtUK8bQ (Podcast)

However, using the librespot standalone binary, it is able to get the information and even playback the episodes

[2025-10-29T14:09:33Z DEBUG librespot_core::http_client] Requesting https://gew4-spclient.spotify.com:443/context-resolve/v1/spotify:show:1IyAJYcVhVN4owCMPNWjSV
[2025-10-29T14:09:33Z DEBUG librespot_connect::spirc] handling next context Some("spotify:show:1IyAJYcVhVN4owCMPNWjSV")
[2025-10-29T14:09:33Z DEBUG librespot_connect::state::context] updated context Default to <Some("spotify:show:1IyAJYcVhVN4owCMPNWjSV")> (286 tracks)
[2025-10-29T14:09:33Z DEBUG librespot_connect::context_resolver] last item of type <Default>, finishing state setup
[2025-10-29T14:09:33Z DEBUG librespot_connect::state::transfer] active track is <spotify:episode:3v7RM7AtydrnsjeTEvlGO6> with index Ok(0) in Default context, has 286 tracks
[2025-10-29T14:09:33Z DEBUG librespot_connect::state::transfer] setting up next and prev: index is at Some(0) while shuffle false
[2025-10-29T14:09:33Z DEBUG librespot_connect::state] reset_playback with active ctx <Default> fill_up ctx <Default>
[2025-10-29T14:09:33Z DEBUG librespot_connect::state::tracks] set track to: spotify:episode:3v7RM7AtydrnsjeTEvlGO6 at 0 of 286 tracks
[2025-10-29T14:09:33Z DEBUG librespot_connect::state::tracks] finished filling up next_tracks (80)
[2025-10-29T14:09:33Z DEBUG librespot_connect::state] updated connect play status playing: true, paused: true, buffering: true
[2025-10-29T14:09:33Z DEBUG librespot_core::http_client] Requesting https://gew4-spclient.spotify.com:443/connect-state/v1/devices/....?product=0&country=DE&salt=2378509623
[2025-10-29T14:09:36Z TRACE librespot_core::dealer] dealer request hm://connect-state/v1/player/command
[2025-10-29T14:09:36Z TRACE librespot_core::dealer::protocol] message was sent with gzip encoding
[2025-10-29T14:09:36Z TRACE librespot_core::dealer::protocol] websocket request: Object {
        "command": Object {
            "endpoint": String("resume"),
            "logging_params": Object {
                "command_id": String("f955f96e87ee87e53e4418a2eb8d2f0c"),
                "device_identifier": String("...."),
            },
        },
        "message_id": Number(810386418),
        "play_on_secondary_stream": Null,
        "sent_by_device_id": String("...."),
        "target_alias_id": Null,
    }
[2025-10-29T14:09:36Z DEBUG librespot_connect::spirc] handling: 'endpoint: resume' from ....
[2025-10-29T14:09:36Z DEBUG librespot_connect::spirc] SpircTask::set_volume(32767)
[2025-10-29T14:09:36Z DEBUG librespot_playback::player] command=Play
[2025-10-29T14:09:36Z DEBUG librespot_core::dealer::manager] replying to ws request: Success
[2025-10-29T14:09:36Z TRACE librespot_playback::player] == Starting sink ==
[2025-10-29T14:09:36Z TRACE librespot_connect::spirc] ==> Playing
[2025-10-29T14:09:37Z DEBUG librespot_connect::state] updated connect play status playing: true, paused: false, buffering: false
[2025-10-29T14:09:37Z DEBUG librespot_connect::state] update position to 0:26 at 14:09:37.174
[2025-10-29T14:09:37Z DEBUG librespot_core::http_client] Requesting https://gew4-spclient.spotify.com:443/connect-state/v1/devices/....?product=0&country=DE&salt=1378805215
[2025-10-29T14:09:40Z TRACE librespot_core::dealer] dealer request hm://connect-state/v1/player/command
[2025-10-29T14:09:40Z TRACE librespot_core::dealer::protocol] message was sent with gzip encoding
[2025-10-29T14:09:40Z TRACE librespot_core::dealer::protocol] websocket request: Object {
        "command": Object {
            "endpoint": String("pause"),
            "logging_params": Object {
                "command_id": String("4ec715eb3c97e061f03e328158cbc432"),
                "device_identifier": String("...."),
            },
            "options": Object {},
        },
        "message_id": Number(810390192),
        "play_on_secondary_stream": Null,
        "sent_by_device_id": String("..."),
        "target_alias_id": Null,
    }
[2025-10-29T14:09:40Z DEBUG librespot_connect::spirc] handling: 'endpoint: pause' from ...
[2025-10-29T14:09:40Z DEBUG librespot_core::dealer::manager] replying to ws request: Success
[2025-10-29T14:09:40Z DEBUG librespot_playback::player] command=Pause
[2025-10-29T14:09:40Z TRACE librespot_playback::player] == Stopping sink ==

Host (what you are running librespot on):

• OS: Arch Linux
• Platform: x86-64

[michaelherger]

502 (or 50x in general) usually are server side problems. They for whatever reason fail to respond to your request. Bad gateway sounds like there was a proxy or load-balancer trying to reach a backend server but didn't get any usable response.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/502

[DamianRyse]

Hi @michaelherger yeah I thought so too, but now I just discovered something else:

As soon as I add a request of the SpClient, the metadata fetching works even tho I'm not using the result in any way.

let _ = session.spclient().get_show_metadata(&spotify_id).await;

// Fetch album with error context
Show::get(session, &spotify_id)
  .await
  .map_err(|e| Error::new(ErrorKind::Other, format!("Failed to fetch show: {}", e)))

If I remove the line again, I'm getting the 502 as before.

[michaelherger]

You've found a bug in Spotify's backend - and a way to reproduce or work around it. You should tell them 😂.

Seriously: I'm not familiar enough with that code to be sure what it is. But it's good to know you have a workaround.

[kingosticks]

Does the first (unused) request also fail? Could you crank up the logging verbosity and manually retry the first "bad" request?

[DamianRyse]

Does the first (unused) request also fail? Could you crank up the logging verbosity and manually retry the first "bad" request?

    let sp_result  = session.spclient().get_show_metadata(&spotify_id).await;
    match sp_result {
        Ok(bytes) => println!("The SpClient request was successful: {} bytes received", bytes.len()),
        Err(error) => println!("The SpClient request failed: {error}")
    }

    // Fetch album with error context
    Show::get(session, &spotify_id)
        .await
        .map_err(|e| Error::new(ErrorKind::Other, format!("Failed to fetch show: {}", e)))

-> The SpClient request failed: Unknown error { Response status code: 502 Bad Gateway }
-> The second request (Show::get()) does work.

It seems the first request fails and the second one succeeds. After testing, I noticed that simply using Show::get() twice also works perfectly fine:

    // Dummy request to catch the first 502 Gateway error
    let _ = Show::get(session, &spotify_id).await;

    // Actual metadata request
    Show::get(session, &spotify_id)
        .await
        .map_err(|e| Error::new(ErrorKind::Other, format!("Failed to fetch show: {}", e)))

[kingosticks]

But I'm curious what's wrong with that first request? Is that our bug or theirs? Can you trace the actual request going out and see are the headers or query params obviously messed up?

[photovoltex]

Could you give https://github.com/photovoltex/librespot/tree/fix/broken-metadata a try? It uses a different endpoint to acquire the data which might resolve the issue.

[DamianRyse]

Could you give https://github.com/photovoltex/librespot/tree/fix/broken-metadata a try? It uses a different endpoint to acquire the data which might resolve the issue.

Yes your fork works great!

[naed437]

Any fix for the java version?

[kingosticks]

We don't know, we do not maintain the java version here.