Hello,
I do like dsubs caching method.
When playing songs it automatically builds a cache with a configurable max size by downloading the current song and the next three.
When the cache size is reached, the oldest song gets deleted.
This greatly increases reliability in regions with bad mobile internet, like Germany, or when driving through tunnels.
Screenshot from dsubs settings page:
This is a duplicate.
But to resume again, the issue is about the cache limit and auto prune.
Symfonium is offline first with many cache functions and auto cache functions those functions requires that the data is not purged as the user expect the data to be here when they need it.
Having a playback cache only makes little sense due to that. Automatic pre caching is not an issue, but without a limit it can cause storage issues.
I currently do not have a proper UI/UX solution to address properly all the cases, usually users create playlists and enable auto cache on them.
Using (smart) playlists would require me to plan ahead what music I would like to listen before getting in the car. But usually I get in the car, select a random album and listen to that.
Caching during Playback helps getting through bad connections and also reduces data usage when listening to the same album multiple times.
Maybe this option can be seen as a different / additional caching option to the current caching option
This is not that simple to have 2 levels of caching with different kind of transcoding profiles and many parameters.
While a small preload cache different from the rest can makes sense, having a large one to reduce data usage a lot less with all the auto cache features.
You’re right, and a large playback cache really isn’t needed. Just the next (couple) songs.
It’s less about offline playback and more about “pre-streaming” for spotty connections 
But if it’s not feasible to implement it, we’ll just have to live with it ^^
Next version will have a playback cache with preloading.
This cache will be 100% independent from the offline cache so should not be used for such usage, there’s no guarantee that content will still be present and usable between sessions and application updates.
Can I follow-up on this topic? I often walk around university buildings, where wifi reach (eduroam) might be patchy. This means the playback from Symfonium stops once in a while, whenever the device is successful connecting from mobile network to wifi and backwards.
Can you please suggest how to avoid these playback interruptions, while walking in areas with wifi/mobile data exchange? DSub’s solution was quite elegant, that
Enable the option playback cache that is meant for that?
Isn’t playback cache a bit too much? I mean the lowest value is 128MB. I want to have pre-cached only 3 songs, not 128MB. With that amount I can easily use all my data… Or does this work progressively, that the max cache is 128MB (if set), and it always pre-loads the next song only?
It’s adaptative and preload based on the size so yes for less than 256Mb only 1 next song is preloaded.
And 128Mb for FLAC is not a lot.
Thanks, maybe a clarification in the documentation would be great about this how this function works.
When I am out and about I do not need a full FLAC preload anyway, and 128MB for 3 OPUS songs is a bit overkill
You missread the option name or there’s a translation issue.
This is the size of the playback cache, so the amount of cached playback data, future and past.
128mb is very small, you’ll nearly never hit it and it only covers network coverage issues. Not reusable cache to reduce network usage.
