mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #51] Panic with message "No space left on device" #42
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#42
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 @sashahilton00 on GitHub (Jan 29, 2018).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/51
Friday Mar 17, 2017 at 09:51 GMT
Originally opened as https://github.com/plietar/librespot/issues/166
When playling long tracks on my embedded device with about 36MB of free RAM, librespot panics with:
thread 'main' panicked at 'calledResult::unwrap()on anErrvalue: Error { repr: Os { code: 28, message: "No space left on device" } }'.For example using this track (45:31). Is there a way not to load the whole song into RAM?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday Mar 17, 2017 at 14:37 GMT
Interesting, I never really considered very large tracks.
librespot doesn't load the whole song into RAM, but it downloads it into
/tmp, which may be the same thing if that is mounted as a tmpfs.As a temporary workaround, you can change this line from
NamedTempFile::new()toNamedTempFile::new_in("/somewhere/not/in/ram").Ideally, if a cache directory is specified we can just use
$CACHE/tempautomatically for that.@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday Mar 17, 2017 at 17:52 GMT
Thanks, I will try this. In fact, this track is an extreme. It my also happen for tracks having a length of six or seven minutes, depending on the free RAM left.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday Mar 23, 2017 at 12:10 GMT
On second thought, my system is NAND flash based. So, using anything else than the RAM for caching is not a good idea. So, I need a bigger RAM?
@sashahilton00 commented on GitHub (Jan 29, 2018):
Thursday Mar 23, 2017 at 13:25 GMT
Pretty much. A solution would be to change
librespotto break up the files in blocks of say 500KB, and delete them automatically (if cache is disabled) once it has moved on to the next one. This is a large-ish change, so it's unlikely I'll be able to implement it anytime soon unfortunately.@sashahilton00 commented on GitHub (Jan 29, 2018):
Tuesday May 02, 2017 at 04:33 GMT
I've modified librespot to disable the audio file-cache. See pull request #181.
@ComlOnline commented on GitHub (Jan 31, 2018):
The final PR for this was closed. See here.
@plietar commented on GitHub (Feb 2, 2018):
This is different from https://github.com/plietar/librespot/pull/204. The issue here is that librespot tries to download the entire file (whether or not cache is enabled), which may be impossible for long tracks and low memory devices.
@michaelherger commented on GitHub (Feb 2, 2018):
Yep, I had to learn this the hard way: though I had the audio-cache disabled I still saw people with large files in TMPDIR. In my case I was able to work around this using the method mentioned by @plietar: have librespot write to some place outside in-memory storage. Setting
TMPDIR=/path/to/folder librespot ...does the trick here.@sashahilton00 commented on GitHub (Feb 2, 2018):
given that all spotify songs are downloaded in chunks, is there an easy way to discard chunks once they have been played when the cache is disabled?