finamp
finamp copied to clipboard
jmshrv
LRU cache
Related to https://github.com/jmshrv/finamp/issues/520 and https://github.com/jmshrv/finamp/issues/796
Proposal to add a simple least-recently used cache with configurable cache size as a temporary measure to improve on-device caching mecanisms. Would improve low data availability situations for some users.
Hi, the problem with that is that the audio backend we're using requests the audio streams and images by itself. We simply pass it the link, and it does the rest. That means that we cannot easily intercept the data, meaning if we wanted to do any kind of caching we would need to request the data twice.
The only solution I can think of would be adding an internal proxy, that forwards the request by the audio backend to the Jellyfin server and then intercepts the HTTP response. That might be a bit more complicated though, so I don't think I'll add that anytime soon myself.
But if anyone feels like creating a PR for that, I'm sure we could get something merged!
Thanks for the reply ! What I thought would be to leverage the download tracks feature that is already builtin, if that is possible in any way ?
Well yes, but as I said, we cannot access the data from the player, so we would need to download it separately instead of truly caching it.
If you just want an option to download each track that was recently played, that would be possible, but would either require mode mobile data or would only happen once you connect to WiFi
I was actually wrong! just_audio, our audio backend, seems to have experimental support for this, using the internal proxy approach I described earlier. I haven't tried this out yet, and I'm not sure how easy it would be to integrate this with the download system, since we would need to somehow integrate the existing cached file into the download database, but without actually downloading the file again.
Maybe @Komodo5197 has more ideas, but it might be possible to implement a pseudo-downloader that just moves the file from the cache directory into the download directory, but behaves like the regular downloader. There might be some refactoring or additional abstraction needed to get this to work though.
We could just treat the cached file as a separate thing, and clean it up if the song is explicitly downloaded
Well yes, but we still need to manage them somehow. And I'm not sure opening a third database for it is a good idea.
Plus all of the metadata fetching and querying/loading the data in offline mode is also needed.
Trying a full metadata fetch for every song played seems unreasonable. My first instinct would be to just not integrate the cache with offline mode, except maybe a file copy on download if possible. That would be complicated by needing to rework the download completion code a bit, and also by having to track and accommodate the various transcode settings. That really doesn't seem very important though, so I'd just not integrate it at all on first pass, and just focus on the basic case of reducing data usage while replaying things in online mode with no impacts while offline.
Hmm, okay. I guess that should be fairly easy to implement. From what I've read just_audio would manage the cache mostly for us by checking if a file already existst for the current URL. If the settings stay the same I think thr URLs we use to request audio should also be similar enough to be considered a cache hit.
And then maybe we just periodically check how big the cache directory is, and delete the oldest files if it's too big.