error audio key, unable to load key #1236
Comments
|
@roderickvd et al. - I'm still seeing the same, running 0.5.0-dev e24fc72. Some podcasts would no longer play, which would still play using 0.4.2 931b4e6. I tried to capture a debug log. Maybe it's of some help. |
I can confirm that @michaelherger's example "Heimat und Abschied: Was die Rückkehr auf den Balkan mit Familien macht" does not play using a recent librespot v0.5.0-dev version. |
|
I have tried to dig a little bit more into that. I have added some debug lines of code inside player.rs, fn load_track() in v0.5.0-dev as well as v0.4.2: I get a different "file_id" depending if I run v0.5.0-dev or v0.4.2, pls. see log: v0.5.0-dev: v0.4.2: Even though the Spotify-ID is the same, v0.4.2 gives another file-id compared to v0.5.0-dev. Unfortunately I'm not familiar with any inside view of Spotify and librespot, so no idea why the two versions results in different file_ids and if this is the root cause for not playing the episode using v0.5.0-dev. |
|
Does this only happen with episodes? I have some thoughts, will look later |
|
FWICT yes. In one case it seemed to not even impact all episodes, but only some, probably the most recent ones. |
While playing around (I thought its maybe related to 96kbps bit-rate) I found that this "error audio key 0 1" appears also for any song I have tried to play when librespot was started with "--bitrate 96". Same as for the episodes: Plays fine with v0.4.2, does not play with v0.5.0-dev. Steps to reproduce:
Log trace for v0.5.0-dev (with additional debug msgs, marked as error): [2024-09-11T20:05:38Z INFO librespot] librespot 0.5.0-dev VERGEN_IDEMPOTENT_OUTPUT (Built on 2024-09-03, Build ID: upyelh1p, Profile: release) Log for v40.4.2 (with additional debug msgs, marked as error): [2024-09-11T20:06:40Z INFO librespot] librespot 0.4.2 UNKNOWN (Built on 2024-09-09, Build ID: lIuLog07, Profile: release) Can someone confirm that "--bitrate 96" also has an issue playing songs? |
|
Could it be related to gew4 being used in 0.5? The 0.4 log contains
@roderickvd do you remember why gew4 is allowed again in 0.5? The specific code to avoid using it isn't there? Is it intentional or accidental? |
|
I remember it was intentional. Don't remember but I think the errors on 0.4 did not seem to apply to 0.5 on that AP. Sorry, can't remember any more details. Does this 96 kbps work again when you ignore that AP? For sure I've never tested that bitrate myself. Or maybe there's something in the code that selects the most appropriate bitrate, that tries to get a key for a different file with different bitrate? Just a wild guess. I do think I touched that piece of code when I added some boilerplate for future FLAC support. |
Yep (v0.5.0-dev) The other two bitrates work fine for me. |
|
This seems like an important regression which must be fixed before 0.5 goes out. Who is willing to work on it? |
@roderickvd This issue happens also when blocking "https://apresolve.spotify.com/" and librespot uses its fallback AP. No idea about other AP's, I have not tried to revert blocking of specific AP's in v0.5.0-dev like done in v0.4.2. v0.5.0 log (with fallback AP): |
|
I have added additional debug prints in v0.4.2 as well as in v0.5.0 inside player.rs, fn load_track() in order to get the AudioItem struct or audio struct respectively. This is the trace for "AudioItem" struct, 96kbps, v0.5.0: This is the trace for "audio" struct, 96kbps, v0.4.2: For v0.5.0 the used file_id results in "9062385e1738325c74fa165c64ba2154873cfece" which is mapped to "OGG_VORBIS_96" in "AudioItem". This fits to my observation that v0.4.2 uses a different file_id compared to v0.5.0 for the same spotify_id. The interesting thing is that the file_id "9062385e1738325c74fa165c64ba2154873cfece" which is used in v0.5.0 is the file_id which is mapped to "AAC_160" for v0.4.2. Beside that there are some more audio formats available when using v0.4.2. I tried to follow up where the "files"-field is populated in v0.5.0 and ended up somewhere in parse_from_bytes() inside messages.rs. No idea about the code there currently.... Edit: |
|
Very interesting! I might be misunderstanding this but the protobuf code here looks a bit suspicious to me. Is it using So if a value isn't defined in the .proto enum (shown below) then it'll be given 0.4: 0.5: |
|
Yes, I think that's what is happening. Adding to the v0.5 proto definition fixes 96kbps playback for me. |
|
Great! Probably should let go of OTHER5 = 0xa which now maps to FLAC_FLAC = 16. |
@kingosticks Thanks a lot. This seems to fix the issue with 96kbps as well as the issue with the podcast episodes. Need to do some more testing.... But just to double check: I found I have to add some code inside player.rs as well to make it compile. I guess that's correct, too? When comparing v0.4 with v0.5, OTHER3 = 9 is now mapped to AAC_48 = 9. I guess that's by intention? |
|
guys, you rock! What would be the minimum change I'd have to apply to test the podcast issue? |
@michaelherger Adding to and adding inside in player.rs is doing the trick for me. |
|
Yes, sorry, I just added something silly to fix the compile error, it wasn't going to actually be using those extra formats. Re the other proto file. I didn't check if we were using that other one but I think in general it makes sense that all code points are covered if the generated proto hides issues like this. I wonder if we can make it emit a warning message or something when it does that. |
|
Excellent! I can confirm that the podcasts which previously wouldn't work any more now are working for me, too (after manually applying the above changes to my own fork). |
|
But I don't understand the issue yet in details. My understanding is: We're requesting information from Spotify (e.g. the file_ids). So I'm wondering: The missing definitions for led to the observed issue with 96kbps and some podcast episodes. What, if Spotify returns a new audio format, something like FANCY_NEW_FORMAT = 0xe in future? We don't have covered that one, too as of today. Will this lead to an issue as well? Edit: |
|
I have same problem with error audio key 0 2. Client show progress playing, but no sound from librespot (latest build from git dev). [2024-09-17T08:50:31Z TRACE librespot_audio::fetch] Streaming from https://audio-ak-spotify-com.akamaized.net/audio/1ec2eb082880af0deb56ec525f0beee995c53c82?__token__=exp=1726649431~hmac=xxx |
Yes.
The issue is the generated protobuf code that parses the bytestream and converts it into the librespot/metadata/src/audio/file.rs Lines 47 to 61 in 22a8850
Yes. And it would be great to avoid that, maybe we can here. But there are probably lots of other places like this. |
|
@kingosticks Ah, ok, I understand. Thanks a lot for your detailed explanation. Now it's clear to me what happens. Avoiding those kind of issues would be great, even though my Rust skills are to limited yet to understand the code by my self and have even a rough idea how to fix... |
|
It seems the protobuf spec allows a default to be set. e.g. But I couldn't get the protobuf parser to accept that. EDIT: Turns out the EDIT EDIT: Or I guess we could change our |
|
The protobufs extracted are in fact proto2 so let's stick to that. Then handling it ourselves would be nice indeed, but let's be honest, also likely an edge case. Who will put in a PR to fix the 96 kbps thing? With or without the default fallback. |
|
I wish I could 😞. |
|
I'm confused now... What I understood so far: The "metadata.rs" file is generated by some generator and located somewhere under ../target/debug/build/.. and ../target/release/build/.. . The input for the generator is "metadat.proto". I assume my understanding is correct so far. Deleted all the generated files related "librespot-protocol" under ../target/debug/build/.. and ../target/release/build/.. just to be sure. Changed using some nonsense values for all non OGG formats, just to provoke a lot of unknown errors (and not touching the rest of the code). I have used "UNKNOWN_FORMAT" for better searching over files, works also with "UNKNOWN". This change results in inside the generated "metadata.rs" file. I added a handler for "UNKNOWN_FORMAT" also in player.rs which seems to be kind of stupid, calculating a data rate for an unknown format. As a result I get this AudioItem struct: and this is the result after all The file_ids seems to be correct (compared to my comment #1236 (comment)) and 96kbps and episodes works well. @kingosticks So basically I just did the same as you have proposed. Can you pls. double check once again on your side that this code works? Do I miss something on my side, is there an error? |
Prevents unknown formats being treated as `OGG_VORBIS_96` and breaking 96kbps playback. Fixes librespot-org#1236.
|
That looks OK to me. In my earlier post I claimed that the Maybe just say the |
|
I like the approach to That's maybe kind of theoretical discussion and the approach to force None by using In sum I see the following code changes up to now: media_manifest.proto (no idea about a default here, but its proto3 syntax anyway, maybe does not work?) : metadata.proto (not sure about the numerical value for UNKNOWN_FORMAT, thought 0xFF would be a good idea): player.rs: and Edit: Edit: |
Yep. Why don't you create a PR with these changes, that's a better place for a review. |
|
I'm not used to work on community projects like this yet. I need to check this pull-request stuff first, I'm not really familiar with Git. Just give me some time. Sorry for some stupid output or questions from my side sometimes, but it seems I have to cache up and ramp up my learning curve with respect to a lot of topics... :-) |
|
See eg. here for an introduction to pull requests: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request. I can't help with the coding, but feel free to reach out to me if you need help with the Github interaction. That way I could at least contribute to the solution of this problem 😁. |
|
I have started a pull request for this issue. Since that's my first community pull request, pls. give some advice whenever I should do things different (e.g. with respect to "best practice") or if there's something wrong. |
|
This was fixed in #1342. |
Describe the bug
Librespot cannot play podcast episode. In this particular situation I'm trying to load "spotify:episode:7CDoCFJUAnwOLPVieM1Us0", "Schenken - Die Geschichte des Gebens und Nehmens".
This issue happens with Librespot dev-branch, compiled as --release (librespot 0.5.0-dev 886617e (Built on 2023-12-10, Build ID: 6mScPS9U, Profile: release).
This issue does not happen with Librespot v0.4.2.
To reproduce
Steps to reproduce the behavior:
Log
[2023-12-27T10:49:23Z TRACE librespot_audio::fetch] Streaming from https://audio-ak-spotify-com.akamaized.net/audio/2916bc99f9878b1197de961a1c15fc572b8086ae?__token__=xxxxxxxxxxxxxxxxxxxxxxxxx
[2023-12-27T10:49:23Z DEBUG librespot::component] new AudioKeyManager
[2023-12-27T10:49:23Z ERROR librespot_core::audio_key] error audio key 0 1
[2023-12-27T10:49:23Z WARN librespot_playback::player] Unable to load key, continuing without decryption: Service unavailable { audio key error }
[2023-12-27T10:49:23Z TRACE librespot_audio::fetch::receive] Time to first byte now estimated as: 27 ms
[2023-12-27T10:49:23Z TRACE librespot_audio::fetch::receive] Throughput now estimated as: 1820 kbps
[2023-12-27T10:49:24Z TRACE librespot_audio::fetch::receive] Throughput now estimated as: 1320 kbps
[2023-12-27T10:49:24Z TRACE librespot_audio::fetch::receive] Time to first byte now estimated as: 20 ms
[2023-12-27T10:49:24Z TRACE librespot_audio::fetch::receive] Throughput now estimated as: 1653 kbps
[2023-12-27T10:49:24Z TRACE librespot_audio::fetch::receive] Throughput now estimated as: 1815 kbps
Host (what you are running
librespoton):Additional context
As already mentioned, the episode plays fine using Librespot v0.4.2 release. I can provide more detailed log for both, Librespot dev-branch and Librespot v0.4.2, both in verbose mode. But I'm not sure which log-information to delete with respect to personal and sensitive data (like tokens, etc.).
The text was updated successfully, but these errors were encountered: