zyrouge / symphony

🎵 Lightweight, elegant music player for Android 9+.
https://zyrouge.github.io/symphony/
GNU Affero General Public License v3.0
1.27k stars 81 forks source link

[Bug] App (temporarily) creates a copy of music library in its internal space filling up all available space #640

Closed BlastboomStrice closed 1 week ago

BlastboomStrice commented 2 weeks ago

Description

First of all, thank you for this amazing update, among others, the app handles song tags much better now (eg. the date displays properly on my (.opus) songs now). There is one (big?) issue though. I think the app tries to temporarily create a copy of all my music files in its user data space (which means around 5mb per song). After it reads the files, it seems like it deletes the songs from the user data, but keeps the tags, thumbnails and lyrics files internally, taking up around 0.5-1mb for each song. I have ~3.500 songs, which is around 13gb of opus and lrc files (and I plan on expanding it), but I only have ~1gb free space. I run out of space a few seconds after letting the app scan my media library. To read my library it would need to initially use ~13gb, which only then it will be reduced to 1-3 gb (or even lower). I can make ~1-2gb of free space, but I probably won't be able to make as much free space as my music library.

Steps to Reproduce

  1. Go to settings
  2. Add your music media folder (or whitelist your music media folder) (Note: I have the path /storage/emulated/0 in blacklist to avoid scanning my whole device.)
  3. As soon as scanning starts check the app data size. If you have less free space (internal, not sd) than your music library, you will see the app data of the app to expand extremely high until you have no free space.

Expected Behavior

Previously, the app scanned the music library (even if it was magnitudes bigger than my free space) and only took around 10mb extra app data (so a total of around 20mb). The app though would need to rescan my library if I ever cleared the cache (even if I think it didn't use ~any cache memory). This is what I expected the app to do now.

Screenshots

No response

Additional Context

One possible way to fix this might be to import the songs in small batches instead of a single huge batch (which could be user defined maybe??). Currently to remove the data it creates, I have to remove the folders from the "media folders" and "whitelist folders", force stop the app to stop scanning and then open it again and press "Clear song cache" (which as expected removes the songs from the app too).

Thank you for your work on this app! Even if you can't fix this somehow, at least I'm happy that a somewhat proper local music player app exists for android, which I could use if I ever have enough space :)

Device

Xiaomi Mi 10 5G

OS

Android 13

Version

2024.11.113

Contribution Guidelines

zyrouge commented 2 weeks ago

The app does not copy any files. Audio files are read using ContentResolver#openInputStream() which should reads the file directly. Lyric files are read dynamically when required. The app does store the thumbnails as files in app's cache. Could you verify if they're just thumbnails or the audio files themselves?

BlastboomStrice commented 2 weeks ago

I have managed to export the covers of my music library and they should take around 2gb (around 0.5mb each). Does the app keep the covers in full resolution or reduces the resolution only after it scans the whole folder? (If any of those is true it might explain the data usage. I lean on the second senario.)

I tried to do a test:

  1. I made a folder with only 80 .opus songs (no .lrc files) which is around 350mb. The app user data without any song imported is under 1mb.
  2. I added the folder to the app.
  3. While the app was scanning the folder, I openned the settings of the app and refreshed the user data storage. It started increasing, from 76mb, to 93mb, to 106mb to 116mb and then suddently (once the scanning stopped) it went down to 60mb where it stayed. I will edit this to provide screenshots (in chronological order). (Thanks for the quick response!)

Screenshot_2024-11-04-13-59-56-659_com miui securitycenter Screenshot_2024-11-04-13-59-58-727_com miui securitycenter Screenshot_2024-11-04-14-00-00-888_com miui securitycenter Screenshot_2024-11-04-14-00-03-070_com miui securitycenter Screenshot_2024-11-04-14-00-05-347_com miui securitycenter

zyrouge commented 2 weeks ago

The app does not compress the image. And, I might have an idea of what is happening here. I think the cache mechanism is somehow failing. Any missed cache is deleted after the scanning is completed which is probably the reason the storage space reduces. By any means are you modifying the files frequently? Frequent changes would keep invalidating the cache.

BlastboomStrice commented 2 weeks ago

By any means are you modifying the files frequently? Frequent changes would keep invalidating the cache.

I used to do that some months ago and recently due to lack of space my phone automaticallh delered the cache. But I think the issue isnt that.

The issue is when the app scans the media folder. As you can see in the screenshots above, during those few seconds of the scan, the app somehow allocates a lot of space in the user data area and once it finishes the scan it drops around in half (from ~120mb to ~60mb).

That's not a big issue for small media libraries, but because I have ~13gb of music files, the app allocates so much space that whole system runs out of space and the app probably can't finish the scan and the whole situation becomes a bit dangerous, like I'm fork bombing the internal space😅.

Is there a way I could provide any useful logs?

zyrouge commented 2 weeks ago

I'll be implementing a fix in the next nightly build, let me know if this is not bad as it is now.

BlastboomStrice commented 1 week ago

Thank youu, I tried this version: v2024.11.114-nightly+f88a4b0 The problem seems to be fixed. The I tried to scan a ~1.000song folder (I had ~3.5gb free) and I saw the app increased very slowly and gradually in space, until it reached ~225mb, much better than prebiously. There was no storage spike, like previously and the app needs around 0.25mb per song. I'm closing it for now:)