-
Notifications
You must be signed in to change notification settings - Fork 630
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to load encrypted file: ChannelError #1322
Comments
Exact same issue here, on |
I've just got the same today via raspotify. Funnily enough it seems to work at some random songs. I'm very confused, seems to be an issue with their backends? |
Same here, been working for the past 4 years without a hitch and suddenly all songs are skipped due to a channel error. Setup on rpi4 with raspotify with librespot 0.4.2 |
Folks I've attempted recompiling and it works when I connected directly to Librespot, do as described here (just compile to release) https://github.com/librespot-org/librespot/blob/dev/COMPILING.md Raspotify still doesn't work, but I can detect Librespot. Don't treat it as a resolution, rather as a workaround. |
I've got the same issue with librespot 0.4.1 88e64bd |
Same here, with both current and old, unsupported, versions. |
There's a workaround at #972 (comment) |
Am I the only one that's seriously mad for being monkeyed around, having to re-configure a working setup for the 100th time when a simple email to the Librespot dev team and 2 weeks notice would have sufficed. Let me tell you a little secret, Spotify, truly, does not give a fuck, about it's customers, and let alone the artists. On the other hand look at us, loyal, paying customers, being fucked over for god knows what time in a row, amazing isn't it. The main question though, how far are going to let them push this stick up our ass? How come, there still isn't no decentralized solution for streaming audio, where the artists also get their commission in FULL, no bullshit middleman. Music is, and always should be by the people, for the people! |
Same started a couple of days ago. My solution: After reading up on this thread I think this might just had been blind luck. Spotify obviously reverted some changes they did. After restoring my hosts file and rebooting, it all started working. Not sure if this fix had any impact. Probably not, I might just have been blind luck that this change and Spotifys reverting was done at the same time. |
@LiD420
Umm. Any chance of a brief explanation of what this does and why it solves the problem? (BTW, as may be obvious from my request, I know nothing about librespot.) |
Hello guys. |
Having the same issue on raspotify for 2 days already. Yesterday I managed to get it working by setting apresolve.spotify.com to 0.0.0.0, but today nothing seems to be working anymore, not even setting the host for individual APs. |
There's a pre-existing related issue at #972 (comment). We need to close one of these. But I'll repeat it here, the workaround is dead already, you need to use the latest code from the dev branch where the issue is not present. |
i can confirm:
|
Adhering to all of the comments related to compiling the dev branch, I'll add that you can also set up Librespot as a service so it runs on startup: |
Hi bitclick, |
@MattGesicki follow the steps just like here https://github.com/librespot-org/librespot/blob/dev/COMPILING.md Note that compilation may take some time. Also compile a release build instead of debug. |
@RSKriegs thanks! |
@MattGesicki I didn't dive into that, I used the default one and it's ok. No it's not a hardware device. However, raw Librespot doesn't work 100% as well as Raspotify for me yet and there are minor issues, but at least it runs. (Most likely some additional setup considerations) |
Compiling from dev does seem to have fixed the issue for me :) |
Compiled from the dev branch on a raspberry pi, worked for me. Use it with Snapcast, no issues so far :) |
Having the same issue on moode. I will compile the dev branch and test with it. [2024-09-03T22:13:50Z WARN librespot_core::apresolve] Using fallback "ap.spotify.com:443"
[2024-09-03T22:13:50Z INFO librespot_core::session] Connecting to AP "ap.spotify.com:443"
...
[2024-09-03T22:24:11Z ERROR librespot_core::channel] channel error: 2 0
[2024-09-03T22:24:11Z ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
[2024-09-03T22:24:11Z WARN librespot_playback::player] Skipping to next track, unable to load track <SpotifyId { id: 3014....., audio_type: Track }>: ()
[2024-09-03T22:24:11Z DEBUG librespot_connect::spirc] At track 10 of 11 <"spotify:playlist:37i9...."> update [true]
[2024-09-03T22:24:11Z TRACE librespot_connect::spirc] Sending status to server: [kPlayStatusPlay] Edit: It is working now after applying these changes: #1322 (comment) |
im running spotifyd 0.3.5 and this issue started happening today for me too, basically my spotify client is completely broken now. (gotta love it when spotify breaks our clients on their end...) |
Can confirm,
|
login is still not working here... |
Got it working again in moode player.
If you made any changes to the |
Can anyone identify which commit from the dev branch fixes this? It might be possible to backport it to other versions. It's not possible for me to just start using dev now because I have a customized fork for an old MIPS router and the newer versions won't work there. |
I hit the issue too and confirm that it is fixed at the tip. I'll try and do a git bisect when I have some time (probably sometime in the next few days) to try and identify the change, since I could not see anything obvious in the commit logs or pull requests that is related. Or maybe one of the devs can chime in if they already know specifically. Might be worth someone tagging a new release given the latest tag doesn't work for a lot of people. |
0.4 (master) and 0.5 (dev) use entirely different methods to retrive the audio data. Spotify probably just disabled the old method used in 0.4, just as they disabled user+password auth. It's very different, it's not going to be a simple change to backport. Everyone will need to move to 0.5 (dev) and there will hopefully be a release of that soon, but a lack of release shouldn't be stopping anyone. |
Can confirm the steps outlined in:
Works for me. - 5th Sept 2024 |
I can confirm this is working. Connection is slow though. And I get the error
But despite that it is working. |
Spotify seems to have rolled back the breaking change. Since they didn't announce the change, and since the old protocol only broke partially (just chunk requests?), maybe the change wasn't intentional in the first place. |
My guess it's all related to #1288 This is exactly what happened when they started deprecating libspotify. Seems they didn't learn much from that mess. |
Probably. I suspect that when it was broken for us, it was broken on all official legacy devices out there. Still, enough reason to start releasing 0.5. |
FYI I'm not getting these errors anymore, with or without the /etc/hosts change. Although I am still having troubles with 1340 ^ |
Are you able to reproduce this issue with the very latest (today's) dev branch code? If so, please provide full debug log showing it occurring. |
@kingosticks How can I test it out? This is how I get 0.4.2: https://github.com/rwjack/addon-snapserver-spotify/blob/f887f5eba609024cb12993393fb0143241c71837/snapserver/Dockerfile#L18 Is it possible for you guys to get an RC out for testing? |
More info about my failed builds on: #1346 We need that RC out, getting this thing compiled is bullshit. |
Describe the bug
All of a sudden I can't play any song
To reproduce
Steps to reproduce the behavior:
librespot
with:Log
Host (what you are running
librespot
on):The text was updated successfully, but these errors were encountered: