-
Notifications
You must be signed in to change notification settings - Fork 632
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
Can't play short files: "Unable to load encrypted file" #510
Comments
I've seen similar reports where people claim that this was a recent change in behaviour (not librespot release related). As if something on Spotify's end had changed, causing this. They also say that the threshold for the track length depends on the bitrate used. Eg. at 96kbps you'd need at least 1:30 to play successfully (https://forums.slimdevices.com/showthread.php?112638-Spotty-Crashing-Help&p=982803&viewfull=1#post982803) |
Looks like that after the first request on the audio file channel a message with |
From above linked thread:
|
I wonder if it is an issue with our chunk size that we try to download. iirc the client chooses the chunk range so it may be that we have quite a large range per chunk, which causes issues for songs with a size less than that of a single chunk. Possibly something to do with this: |
@sashahilton00 I've tested first chunk requests for 4..=1024*16 bytes and unfortunately it does not help. Shifting the initial offset above 0 also has no effect. What about the other content of the chunk request? There's a couple of magic numbers: https://github.com/librespot-org/librespot/blob/dev/audio/src/fetch.rs#L480-L488 |
I once tried tweaking them, they seem to do nothing. |
It's been a very long time since I looked at the audio download logic, and I can't remember if we moved to HTTP retrieval or if we still pull the files via Mercury. If it is indeed a size issue, the client sends an options header before downloading files, my guess is that header returns the file size, which is used to work out the chunk size used for download. |
librespot is still using Mercury channels for downloading audio. Even if we move to HTTPS transport, the audio keys would still need to be fetched over Mercury, is that correct? |
Yes, the audio key system is still the same. |
FYI I am still getting occasional channel errors but I seem to be able to play short songs again now. |
I doubt this is a coincidence, but one of my users reported a very similar observation only minutes after you. All the short tracks I've tested indeed do play again. |
Interesting! Unfortunately a bunch of other songs now fail for me (#519) but at least all the short ones work... |
Another data point, if it's helpful -- I've had my librespot (via raspotify) stopping on every 2nd or 3rd track today.
That track is this which is 4:00 so not a "short track". Build:
A few more failing tracks:
|
Another data point, a 3m20s track, reliably failing to play (for me at least):
|
I'm going to close this issue as well as it seems there are no further problems playing short songs. Spotify seem to have rectified the problem at their end. The other issue causing problems playing longer songs is covered in #519 which is also resolved now as well. |
If you try to play a short file (not sure of the exact length, but seems like under 30 seconds), playback fails:
Songs of 40 seconds or longer on the same albums seem to load and play fine, and the failing short songs also play fine through the web browser client.
Here is a sample playlist with only songs that fail in librespot.
The text was updated successfully, but these errors were encountered: