Unexpected large amount of storage used

App version

Production

Issue description

Symfonium uses an unexpected large amount of storage, which may be partly a bug, but probably just some lack of understanding on my side.

My whole library takes about 57 GB (on my server) and I configured the media provider to use persistent cache for the whole library and images, but my phone shows in the storage settings that Symfonium actually uses 77 GB. The app itself says that it uses 45 GB for offline files. I have already run a cleanup and the number of downloaded files matches the number of songs in my library.

I suspect that the remaining 32GB are for the persistent losless image cache (which I’ve enabled), though the app doesn’t show how big the image cache really is and the numbers still don’t really add up to me.

I guess I don’t understand how the persistent image cache is working in the first place. I assume it affects all images of the image provider, but does that include embedded artworks of songs in the persistent cache? Like are they stored twice now? Are images cleaned up if a song/artist/album is removed? Are images replaced if they change on the media provider? And since the app claims that it needs 12 GB less to store the same songs as on my server, I assume the songs are stored without the embedded artwork? Does that then mean, that an artwork is only stored once per album or is there a copy of the artwork for each song of the same album in the image cache?
I mean it doesn’t really make sense to me why the image cache would be that big, but I don’t see why symfonium would use so much more storage. Maybe there are a lot of duplicates or unused images in the cache now? Can I somehow repopulate the image cache without touching the other caches, to test my theory?

Is there another way to find out, what symfonium is using the storage for exactly?

Device type

Phone

Media provider

Navidrome

Steps to reproduce

I don’t know how this happened or if it is expected, so it is impossible to reproduce this for me. For the same reason I am not able to provide logs. I will happily provide them, if there is any theory on how this is happening and how to reproduce. For now I can only tell that something is wrong, but not what exactly, since the app is not providing enough information for me to pinpoint the issue.

Because I have to provide some logs, I recorded logs for my last sync, but I don’t know if this is even related or helpful. This issue is really more about understanding the caching mechanism, because the documentation didn’t answer my questions.

I searched existing issues first

on

I understand that logs are mandatory

on

Log upload name / description

lastsync-too-much-storage

I can’t answer rhetorical questions, yes images takes size specially with Navidrome that returns different images urls per songs.

There’s playback cache, database, possible transcoding left overs, you can cleanup internal states, cleanup image cache, cleanup playback cache.

I’m sorry, I didn’t mean to be rhetorical here. These were honest questions, as the documentation doesn’t talk about these things. Not that I would expect it to, but its just not feasible to find the root cause without an understanding of what is expected to be in the image cache and what not. There is a hundred different ways to implement such a cache.

My playback cache is limited to 200MB and transcoding is disabled. I hardly doubt that the database would take more than a gigabyte for ~5000 songs, but I have no idea what I should expect here, especially with waveforms enabled. Just for good measure I have now:

  • Cleaned up internal state (freed ~150MB)
  • Cleared the playback history (freed <10MB)
  • Compacted the database (increased usage by 80MB)
  • Cleared the playback state (freed ~50MB)
  • Cleared the scraped artist and info cache (freed <10MB)
  • Cleared the media info cache (freed <10MB)

I can cleanup the image cache, yes, but then I won’t be able to find out why the cache got that big in the first place. If there is a bug here, I now have the chance to look deeper into it, I just don’t know where to look and what is considered expected behavior.

Still, 77GB in the app vs 57GB in Navidrome seems excessive to me. Is that much expected?

Read what I write ?

yes images takes size specially with Navidrome that returns different images urls per songs.

With hi res images the cache store at hi res, so a 4mb image per tracks for 5000 tracks is 20 GB.

The app does what you tell it to do.

There’s a settings in Navidrome to not do that.

I read that, but you didn’t give any reason why the app would take so much more storage than on my server or alternatively simply answer my questions to figure it out for myself, which is why I have to ask again.

The app says it uses 45GB for offline files. Add 20GB for images and there are still 12GB used more than you are suggesting. Also I only have high resolution artworks for only about 1000 of my songs, the other ones are 320x320, so 20GB isn’t even an realistic estimate. But ultimately, if I can store all songs plus an artwork for each of them within 57GB on my server, I expect Symfonium to use the same. Otherwise there must be some duplicates or unused images somewhere, no?

I already told you all the things that take space ..

AGAIN: I CAN NOT ANSWER RHETORICAL QUESTIONS I HAVE NO WAY TO KNOW THE SIZE OF YOUR IMAGES AND WHAT YOU DID OVER HOW LONG IN THE APP …

There’s users using 500mb webp images …

Clear the image cache and see the things only you can see …