mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1322] Unable to load encrypted file: ChannelError #601
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#601
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 @rwjack on GitHub (Sep 2, 2024).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1322
Describe the bug
All of a sudden I can't play any song
To reproduce
Steps to reproduce the behavior:
librespotwith:Log
Host (what you are running
librespoton):@moretea commented on GitHub (Sep 2, 2024):
Exact same issue here, on
nixos-23.11. Will update to latest nixos, to see if it will work.@RSKriegs commented on GitHub (Sep 2, 2024):
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?
@guillaume-duroy commented on GitHub (Sep 2, 2024):
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
@RSKriegs commented on GitHub (Sep 2, 2024):
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.
@joeadam commented on GitHub (Sep 2, 2024):
I've got the same issue with librespot 0.4.1
88e64bd@b3nis commented on GitHub (Sep 2, 2024):
Same here, with both current and old, unsupported, versions.
@kingosticks commented on GitHub (Sep 2, 2024):
There's a workaround at https://github.com/librespot-org/librespot/issues/972#issuecomment-2320943137
@rwjack commented on GitHub (Sep 3, 2024):
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!
@ghost commented on GitHub (Sep 3, 2024):
Same started a couple of days ago.
ERROR librespot_playback::player] Unable to load encrypted file: ChannelError
My solution:
/etc/hosts
0.0.0.0 apresolve.spotify.com
104.199.65.124 ap-gew4.spotify.com
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.
@sowthistle commented on GitHub (Sep 3, 2024):
@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.)
@OK9UWU commented on GitHub (Sep 3, 2024):
Hello guys.
Suffering from the same issue as y'all do, tried to add the DNS records but to no avail, the error stands solid.
Using librespot on libreelec and armbian. :/
@codydubat commented on GitHub (Sep 3, 2024):
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.
@kingosticks commented on GitHub (Sep 3, 2024):
There's a pre-existing related issue at https://github.com/librespot-org/librespot/issues/972#issuecomment-2320943137. 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.
@bitclick commented on GitHub (Sep 3, 2024):
i can confirm:
cargo build --release --no-default-features --features alsa-backend(i use the pipe-backend to snapcast)0.4.2i think)@RSKriegs commented on GitHub (Sep 3, 2024):
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:
https://github.com/librespot-org/librespot/wiki/Running-as-a-service
Works on Raspbian for me. I run it as an user service. If you compile this & point the compiled file in ExecStart parameter in librespot.service (or whatever you name it) file you should succeed. Basically everything is in Librespot's documentation :) Hope I've saved someone's time and that it will work consistently.
@MattGesicki commented on GitHub (Sep 3, 2024):
Hi bitclick,
Thank you for the solution, I experienced the same problem.
Could you please provide me and other 'mortals' a quick guide how to implement a fix?
Where I can find latest dev branch and documentation to follow?
Thanks in advance!
@RSKriegs commented on GitHub (Sep 3, 2024):
@MattGesicki follow the steps just like here https://github.com/librespot-org/librespot/blob/dev/COMPILING.md
If you want to add it as a service so it boots on a startup do the following: https://github.com/librespot-org/librespot/wiki/Running-as-a-service
Note that compilation may take some time. Also compile a release build instead of debug.
@MattGesicki commented on GitHub (Sep 3, 2024):
@RSKriegs thanks!
I learned a few things today which are obvious for you :)
I've installed rust and C compiler, added ssh publickey, forked librespot and downloaded it.
One last thing before trying to compile - I'm not sure what audio backend I have. Do they mean a hardware device I use in RaspberryPi?
@RSKriegs commented on GitHub (Sep 3, 2024):
@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)
@fnndyl commented on GitHub (Sep 3, 2024):
Compiling from dev does seem to have fixed the issue for me :)
@kosmo2k commented on GitHub (Sep 3, 2024):
Compiled from the dev branch on a raspberry pi, worked for me. Use it with Snapcast, no issues so far :)
@lpicanco commented on GitHub (Sep 3, 2024):
Having the same issue on moode. I will compile the dev branch and test with it.
Edit: It is working now after applying these changes: https://github.com/librespot-org/librespot/issues/1322#issuecomment-2328404268
@Semmu commented on GitHub (Sep 3, 2024):
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...)
@User65k commented on GitHub (Sep 4, 2024):
Can confirm,
cargo install --git https://github.com/librespot-org/librespot.git --branch dev --no-default-features --features alsa-backend./etc/hostschanges dont help@thomasbuesser commented on GitHub (Sep 4, 2024):
login is still not working here...
@LosTigeros commented on GitHub (Sep 4, 2024):
Got it working again in moode player.
devbranch following this, and to build, use this command:cargo build --release --no-default-features --features alsa-backendlibrespotto the/usr/bin/:sudo mv /usr/bin/librespot /usr/bin/librespot.old && sudo cp target/release/librespot /usr/bin/librespotAutoplayis set toNo, otherwiselibrespotwill just error and stop.ap-portparameter, otherwise it won't be able to resolve all access points:sudo nano /var/www/inc/renderer.php- line 110Change
' --ap-port 13561 'to empty'', or comment it out like this:''; //' --ap-port 13561 'so you can restore it once there is a proper fix.Save the changes (CTRL+O and then CTRL+X)
sudo rebootIf you made any changes to the
/etc/hostsfile like recommended above, please remove those entries before rebooting.@arthurus commented on GitHub (Sep 4, 2024):
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.
@dspearson commented on GitHub (Sep 4, 2024):
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.
@kingosticks commented on GitHub (Sep 4, 2024):
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.
@whisperzer0 commented on GitHub (Sep 4, 2024):
Can confirm the steps outlined in:
https://github.com/librespot-org/librespot/issues/1322#issuecomment-2328160807
Works for me. - 5th Sept 2024
@dflvunoooooo commented on GitHub (Sep 5, 2024):
I can confirm this is working. Connection is slow though. And I get the error
But despite that it is working.
@ejurgensen commented on GitHub (Sep 6, 2024):
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.
@kingosticks commented on GitHub (Sep 6, 2024):
My guess it's all related to https://github.com/librespot-org/librespot/discussions/1288
This is exactly what happened when they started deprecating libspotify. Seems they didn't learn much from that mess.
@roderickvd commented on GitHub (Sep 7, 2024):
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.
@rwjack commented on GitHub (Sep 23, 2024):
FYI I'm not getting these errors anymore, with or without the /etc/hosts change. Although I am still having troubles with 1340 ^
@kingosticks commented on GitHub (Sep 23, 2024):
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.
@rwjack commented on GitHub (Sep 23, 2024):
@kingosticks How can I test it out?
This is how I get 0.4.2:
github.com/rwjack/addon-snapserver-spotify@f887f5eba6/snapserver/Dockerfile (L18)Is it possible for you guys to get an RC out for testing?
@rwjack commented on GitHub (Sep 29, 2024):
More info about my failed builds on: https://github.com/librespot-org/librespot/issues/1346
We need that RC out, getting this thing compiled is bullshit.