mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #510] Can't play short files: "Unable to load encrypted file" #323
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#323
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 @Malvineous on GitHub (Jul 26, 2020).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/510
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.
@michaelherger commented on GitHub (Jul 27, 2020):
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)
@jpochyla commented on GitHub (Jul 27, 2020):
Looks like that after the first request on the audio file channel a message with
CHANNEL_ERROR(0x0a) command and error type 0x00 is received, and the channel gets closed and stays silent after that. I've tried to lower the initial request size, but it didn't help.@michaelherger commented on GitHub (Jul 27, 2020):
From above linked thread:
@sashahilton00 commented on GitHub (Jul 27, 2020):
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:
const MINIMUM_DOWNLOAD_SIZE: usize = 1024 * 16;though would need to explore further to see if this is responsible for what I think it is.@jpochyla commented on GitHub (Jul 27, 2020):
@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
@devgianlu commented on GitHub (Jul 27, 2020):
I once tried tweaking them, they seem to do nothing.
@sashahilton00 commented on GitHub (Jul 27, 2020):
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.
@jpochyla commented on GitHub (Aug 3, 2020):
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?
@devgianlu commented on GitHub (Aug 3, 2020):
Yes, the audio key system is still the same.
@Malvineous commented on GitHub (Aug 15, 2020):
FYI I am still getting occasional channel errors but I seem to be able to play short songs again now.
@michaelherger commented on GitHub (Aug 15, 2020):
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.
@Malvineous commented on GitHub (Aug 15, 2020):
Interesting! Unfortunately a bunch of other songs now fail for me (#519) but at least all the short ones work...
@wlonkly commented on GitHub (Aug 15, 2020):
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:
@Malvineous commented on GitHub (Aug 15, 2020):
@wlonkly Looks like you're encountering issue #519 as well
@gnosek commented on GitHub (Aug 16, 2020):
Another data point, a 3m20s track, reliably failing to play (for me at least):
@wlonkly commented on GitHub (Aug 16, 2020):
Hah, I looked at both and thought "Well, what are the odds of this being BOTH bugs?" and picked one. I guess the odds are higher than I thought! Followed that one too. If I knew a bit of Rust I'd dig deeper, but I don't :/
@Malvineous commented on GitHub (Aug 22, 2020):
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.