mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #34] Limit cache size #22
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#22
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/34
Friday Jul 29, 2016 at 19:50 GMT
Originally opened as https://github.com/plietar/librespot/issues/105
For people running librespot on hardware with limited resources, it would be nice to have an option to limit the cache size.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Friday Jul 29, 2016 at 20:04 GMT
This is definitely something I'd like to have, but requires quite a bit of work.
At the moment, caching is just a matter of placing the file in the cache directory, and trying to open it when loading.
This requires some bookkeeping to keep track of what files are in the cache, their size, along with an eviction algorithm.
These could be used as inspiration, although librespot doesn't need something as sophisticated :
https://wiki.mozilla.org/Necko/Cache
https://www.chromium.org/developers/design-documents/network-stack/disk-cache
@sashahilton00 commented on GitHub (Jan 29, 2018):
Tuesday Nov 29, 2016 at 14:16 GMT
For the moment, users that face issues with it, they could make a simple cron-job that checks the atime of files tp clean-up.
@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Feb 22, 2017 at 13:22 GMT
@mfonville how is this possible? If I run
find /tmp/librespot/files/* -atime +2 -exec rm {} \;it crashes librespot. The only way I can get it to work is to stop the librespot service, clear up the files and start it again. If I do this, the music will stop when playing, so it doesn't seem to be the most ideal solution yet :)@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Feb 22, 2017 at 14:33 GMT
@juriansluiman Deleting files while librespot is running should work.
Can you run librespot with
RUST_BACKTRACE=1and--verboseand post the log please ? What platform are you running on ?@sashahilton00 commented on GitHub (Jan 29, 2018):
Wednesday Feb 22, 2017 at 15:10 GMT
@plietar sorry, you get forget my comment. I was having another issue with librespot so it stopped working, but just tried again and it does continue to play. My bad!
@sashahilton00 commented on GitHub (Jan 29, 2018):
Tuesday May 02, 2017 at 04:34 GMT
I've modified librespot to disable the audio file-cache. See pull request #181.
@shawaj commented on GitHub (Jan 31, 2021):
Any progress on this @sashahilton00 ?
@Sojiro84 commented on GitHub (Feb 13, 2021):
Wondering the same. I just discovered that librespot is taking up 41.8GB of data.
That is a lot for something that should just stream audio!
@debdrup commented on GitHub (Feb 16, 2021):
For a simple algorithm, would it make sense to evict the oldest cached files, either by creation or modification date, when the cache grows beyond a certain size?
As long some code gets added to fix this issue, I'm not sure it needs to be optimal or perfect.
It's definitely better than having a library be responsible for taking up any available diskspace on a long enough timescale.
@sashahilton00 commented on GitHub (Feb 16, 2021):
Nope, no progress. We did discuss it a little in another issue, I can't remember which one exactly, will check when I get home. Ideally we would separate the cache logic out, as there are a few use cases/requirements, eg. Limiting cache by size and/or date, or disable the cache all together.
I can appreciate that in the meantime though it would be better to have something rather than nothing, so if someone does want to throw together a PR that implements a basic cache eviction function, we'll look at getting it merged. If no one wants to, I'll try and give it a go at a later date, but currently I have limited time, and there are a couple of other features that take priority imo, such as retrieving files from the CDN or session reconnection.
@ashthespy commented on GitHub (Feb 16, 2021):
I have an old branch with a simple LRU based file cache implementation with a prescribed limit, can hunt things up if someone would like to work on it..
@woodruffw commented on GitHub (Feb 21, 2021):
I'm completely new to this project, but I'm happy to take a stab if someone has a partial implementation.
@azrdev commented on GitHub (Feb 21, 2021):
I have deployed the following systemd units:
Obviously depends on systemd and the filesystem correctly tracking access times,
then deletes all cached files not accessed for the last 30 days
@debdrup commented on GitHub (Feb 21, 2021):
While that's a good temporary hack for some, it's not really a solution.
Firstly, because it isn't cross-platform (even if it were to be included with librespot, which exists where systemd does not) and secondly, because it's not a POSIX-compatible invocation of find.
It's also not okay for libraries or programs to take up arbitrary disk space without ways of cleaning up after themselves.