Dynamic Caching - the plan?

[palitu]

TL;DR - i am interested in what the plan for offline media is, especially around dynamically cached songs.

I am hunting around for an Open subsonic capable client, but one of the things that i am keen on it having is a "dynamic cache". As in, whatever song it plays, it keeps a local cache, up to a certain/configurable size. Ultimately it has some way of determining what should be kept, based on playing habits.

When offline, the app reverts to a "local" only player, and is aware of what it has available to play, so that we can keep the party going.

This would be in addition to any items marked to download.

I guess, i dont want to have to think about keeping whatever i have been listening to stored locally, in the case that i lose connectivity. It will allow me a limited set of music that I can listen to.

I have been reading the issues and new features, and they are all pretty exciting - pre-cache next song, etc.

Is there any plans for being an online first, offline second type of app, that tries to provide a good (if not great) listening experience during unexpected outage, as well as reducing bandwidth for re-listens of existing songs?

Cheers!

[eddyizm]

Hi @palitu
We have a planned offline mode milestone, which while it is not exactly what you are mentioning, heavily overlaps with the end result of UI/UX for the user.

That being said, the dynamically caching is a feature I've started to work on specifically as keeping tracks locally while streaming them without explicitly downloading each one is something I have used in the past and love.

It is however, not simple. Mostly because we have 2 download paths, the external file and the internal cache one. Making both behave the same has been a real challenge. Creating an offline mode would basically be an effort to mimic the online mode with local content, a dedicated switch to that and in my mind, a quick fall back when there is connectivity issues with no gap. A lot of heavy lifting has been going on in first understanding the current state and the small steps needed to get to the future state.

Please take a look at the milestone and related tickets to get a good idea of what we are trying to do, what has been done, etc.

[palitu]

Hey @eddyizm ,

Thanks, i have finally gotten around to having a look at the above.

Interesting set of use cases for offline, and it sounds like a lot of them are "edge" features for the underlying on-device database work that needs to enable it.

It sounds like when you have your offline storage and DB, your ability to implement a whole range of offline capabilities will be massive, so i totally get that there is foundational work to do yet.

I would add to the offline miliestones:

1. The preference for pre-downloaded tracks to be played, before streaming an online track
2. All played tracks data is saved in a cache that has some sort of eviction policy (ie TTL or MB/GB)
3. The ability to play songs offline from the cache, and how it is discoverable (in some sort of rudimentary way)
4. The ability to store playlists offline, and to map tracks to both online and internal sources.
5. the ability to play offline playlists

This would also be in addition to the milestones on the list, but would allow you to build up capability organically, before trying to manage a TB library sync, as per one of the requests.

any - great work :)