mirror of
https://github.com/devgianlu/go-librespot.git
synced 2026-04-26 21:35:49 +03:00
[GH-ISSUE #235] failed retrieving aes key with code 1 #150
Labels
No labels
bug
enhancement
pull-request
spotify-side
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/go-librespot#150
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @tooxo on GitHub (Oct 21, 2025).
Original GitHub issue: https://github.com/devgianlu/go-librespot/issues/235
On some songs go-librespot seems to be unable to resolve the file id.
This is also not solved with a restart. (Using:
f4e53554b6)@devgianlu commented on GitHub (Oct 24, 2025):
I am seeing an increase in
failed retrieving aes key with code 1errors on my side too.@devgianlu commented on GitHub (Oct 27, 2025):
Don't quote me on that, but I think they are prepearing to shut down the old key retrieval method.
@kingosticks commented on GitHub (Oct 27, 2025):
How often are people seeing this? We've seen no reports of this on librespot. It's possible the retry logic is different and hiding it.
@devgianlu commented on GitHub (Oct 27, 2025):
This is happening to me quite a lot now, like 1 in 4 tracks cannot be played. It's been a while since they last fiddled with this API.
@kingosticks commented on GitHub (Oct 28, 2025):
I had a closer look and I think if we were seeing
AesKeyErrorin librespot we'd be getting error messages for that and people would be reporting those. So that's odd.Edit: Maybe worth trying to play the same track with librespot and see if you see the issue then? We have not moved over to storage resolve V2 or the other metadata endpoint. Are the returned fileid/gids different between the old and new endpoints?
@devgianlu commented on GitHub (Oct 28, 2025):
Does librespot retry key requests on error? I am still getting the same behaviour as yesterday, 1 in 4 tracks cannot be played. I haven't tested whether they are the same tracks or random ones. For example, I cannot play the track posted by OP.
@kingosticks commented on GitHub (Oct 29, 2025):
No, no retry, I think it carries on without a key in case it's a file without encryption (I don't know if that's ever available for audio tracks).
I don't think I can play the OP's track directly, for me (in the UK) it resolves to spotify:track:6xoKWTiw0jVO3IvEKLxMSs with fileId 2e205eff999ed319b318c8ce1d4e94083fd2d2a4 for OGG_VORBIS_320.
With librespot I can play that consistently, like all other tracks.
I couldn't get go-librespot to work under the environment I have here (WSL2 and a corporate firewall). My Windows desktop Spotify client disconnects after the first play attempt. I have no idea why (other than it's not related to any key issues).
@darionis commented on GitHub (Nov 10, 2025):
I am facing the same issue, "aes key code 1". I can play one song, no problem, but then playing stops with the "aes key" error.
I use go-librespot on RPi (OSMC) to connect and controll it form laptop or phone. It worked perfectly until a month ago.
When I restart go-librespot, I can play the very same song which failed minute ago.
@tooxo commented on GitHub (Nov 10, 2025):
One possible mitigation i would propose is just skipping those songs for now, keeping an error in the logs.
@tagdara commented on GitHub (Nov 11, 2025):
Seeing this repeatedly on my system. I use a python app based on Tekore to feed librespot-go tracks and have not made it 10 songs in a row for the last couple days without this error. Skipping once or twice jumpstarts it for a bit.
@kleinnic74 commented on GitHub (Nov 11, 2025):
I've had the same problem and could not play any song, but after changing "flac_enabled: true" to "flac_enabled: false" in the config, songs started playing again without problem. No songs skipped so far.
@NezarecSh commented on GitHub (Nov 15, 2025):
can you confirm this is still working?
edit: i've tried to do that on my RPI 4 and it didn't work for me.
@NezarecSh commented on GitHub (Nov 15, 2025):
I'm not sure if it matters but I noticed its related to albums. if a song isn't playing, then the whole album it was released in won't play either and give this error:
time="2025-11-15T14:36:58Z" level=warning msg="failed handling dealer request" error="failed loading current track (load context): failed creating stream for spotify:track:6cHYuLc3W90bBlpgCQv2bs: failed retrieving audio key: failed retrieving aes key with code 1"@kleinnic74 commented on GitHub (Nov 17, 2025):
I checked again today and consistently got the "failed retrieving aes ke with code 1" for every song when enabling flac. For the same songs, when disabling flac, things worked smoothly.
However, I do get the error every now and then also with Ogg Vorbis songs, but could not recognise a pattern.
@tagdara commented on GitHub (Nov 26, 2025):
I added a retry in my player when receiving a 500 error on the websocket as a work-around, but typically once a song fails, the retries don't work either. Skipping to another song until there's no 500 is the only way I've been able to keep my music playing. Here's what the librespot-go (running in docker) log looks like.
Combined with the volume level problems in my other issue, it's in pretty rough shape and requires a lot of babysitting now.
@dflvunoooooo commented on GitHub (Nov 28, 2025):
I am seeing this error more often over the last week too. It started with one or two songs not playing and now the biggest part of a playlist can't be played.
@dflvunoooooo commented on GitHub (Dec 1, 2025):
I am not having this problem with the rust librespot version.
@iVolt1 commented on GitHub (Dec 1, 2025):
I am seeing this too on new a build from the master today. After the track had the error I skipped to the next track which played ok. I then skipped back twice to the track that errored and it errored again.
@tooxo commented on GitHub (Dec 1, 2025):
What i found interesting in comparison to the librespot client:
Update:
Looking inside the debugger, it seems like go-librespot does not care if the song is not allowed to be played anywhere as seen here:
So the solution seems to be to request the track listed inside the "alternative" field of the extended-metadata response, which in the case of the track listed in the response above already contains the working file ids. This seems to have been removed in
c7a5da1e9a, maybe @devgianlu can explain why.@devgianlu commented on GitHub (Dec 2, 2025):
Thank you @tooxo for the investigation, that seems to be the culprit indeed. I filed a PR which makes the tracks playable again, can you give it a try?
@devgianlu commented on GitHub (Dec 2, 2025):
I've merged the fix, please let me know if the issue persists.
@tooxo commented on GitHub (Dec 2, 2025):
Was just able to test it, seems to at least work with the tracks that did not yesterday.
@devgianlu commented on GitHub (Dec 2, 2025):
This track does not seem to play, even with the changes: https://open.spotify.com/track/79L8Au1ipSKjIXK2ZggRfP
@NezarecSh commented on GitHub (Dec 2, 2025):
This track does not seem to exist on spotify. I couldn't find it at least. I think it's unrelated to go-librespot
Edit: the entire album (Godfather) doesn't seem to exist lol