maxrave-dev / maxrave-dev/SimpMusic
Smart automatic song cache with configurable storage limit and shared cache/download storage
Nobody has claimed this yet.
- Dominant language
- Kotlin
- Stars
- 11.4k
- Forks
- 599
- Avg merge
- 3d 18h
- Merged PRs (30d)
- 7
Description
Problem Description
Problem Description
SimpMusic already supports caching and offline playback, but I would like an option for the app to automatically keep songs I listen to fully cached on the device.
The idea is to make recently played music available offline automatically, without requiring me to manually download every song.
I would also like the automatic cache and manual downloads to reuse the same stored audio whenever possible, instead of keeping duplicate copies of the same song.
Proposed Solution
Add an optional "Smart Offline Cache" feature.
Suggested behavior:
- When a song is played, SimpMusic continues caching/downloading the complete track in the background.
- The user can choose a maximum cache size, for example:
- 2 GB
- 5 GB
- 10 GB
- 20 GB
- Custom
- Once the automatic cache reaches the selected limit, SimpMusic removes the least recently used cached songs.
- Manually downloaded songs should be pinned and should never be automatically removed by the cache cleanup.
- If a song is already fully cached and I press Download, SimpMusic should reuse the existing cached audio instead of downloading/storing another copy.
- If a downloaded song is removed from Downloads, it could optionally become normal cache again instead of deleting the audio immediately.
- It would be useful to have an "On device" or "Cached" view so users can see which songs are currently stored locally.
Example:
Play Song A
→ Song A becomes fully cached
→ stored once on the device
Later press Download on Song A
→ existing cached copy is marked/pinned as Downloaded
→ no duplicate copy is created
If the user later removes the download:
→ the same file can become normal evictable cache again.
Why this would be useful
This would make offline listening much more seamless.
For example, if I set a 10 GB cache limit, songs I regularly listen to would gradually become available offline automatically. Older cached tracks could be removed when space is needed, while songs I explicitly download would always remain available.
It would also avoid wasting storage by keeping both a cached copy and a downloaded copy of the same song.
Optional enhancement
It would also be useful if fully cached/downloaded songs could optionally be exported as normal audio files to Android's Music/Download folder so they can be played by other local music players.
There is already a separate feature request about exporting downloaded songs as local audio files, so this part could remain separate if preferred.
Proposed Solution
Add an optional "Smart Offline Cache" feature that automatically keeps songs I listen to fully cached on the device.
Suggested behavior:
- When a song is played, SimpMusic continues caching the complete track in the background.
- Let the user choose a maximum automatic cache size, for example 2 GB, 5 GB, 10 GB, 20 GB, or Custom.
- When the cache reaches that limit, remove the least recently used auto-cached songs first.
- Manually downloaded songs should be pinned and should never be removed by automatic cache cleanup.
- If a song is already fully cached and the user presses Download, reuse the existing stored audio whenever possible instead of storing another copy.
- If a downloaded song is removed from Downloads, it could optionally become normal evictable cache again instead of immediately deleting the stored audio.
- Add an "On device" or "Cached" view so users can see which tracks are currently stored locally.
Example:
Play Song A
→ Song A becomes fully cached
Later press Download on Song A
→ SimpMusic reuses the existing cached audio
→ marks it as Downloaded/Pinned
→ no duplicate copy is stored
The goal is to have one on-device copy of the audio where possible, with different retention states:
Auto-cached = can be automatically evicted
Downloaded = pinned and kept until the user removes it
Alternative Solutions
Some simpler alternatives could be:
-
Keep the current cache/download systems separate, but allow the user to increase the playback cache size and add a view showing which songs are fully cached.
-
Add an option such as "Automatically download recently played songs", with a configurable storage limit.
-
When the user presses Download on a fully cached song, copy/promote the cached data into the download system instead of downloading the song again.
-
Add a manual "Keep offline" action for cached songs that pins an existing cached track so it is not evicted.
These would still improve offline playback, although sharing the same stored audio between cache and downloads would be more storage-efficient.
Additional Context
The main reason for this request is seamless offline playback and avoiding unnecessary duplicate storage.
For example, if I configure a 10 GB automatic cache, songs I listen to regularly could gradually become available offline without manually downloading every track. Once the limit is reached, older auto-cached tracks could be removed, while manually downloaded tracks remain pinned.
I do not think every cached song needs to appear under the existing Downloads page. A separate "Cached" / "On device" section would probably keep the UI cleaner.
It would also be useful in the future to allow fully cached/downloaded tracks to be exported as normal audio files to Android's Music/Download folder for playback in other local music players, but that could be handled as a separate feature since it is not required for the smart cache idea.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
No files, tests, or entry points are named. Start by locating the existing playback cache, download storage, and Downloads UI paths, then determine how they could share one stored track. Done should include configurable cache limits, least-recently-used eviction that preserves downloads, promotion of cached tracks without duplication, and a way to view cached content.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, kotlin
- Domain
- mobile
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 30/100