I notice when I am playing music my phone gets really warm and the battery rapidly decreases. In the app usage the overwhelmingly bulk of it is from symfonium. Just curious if it is something in the logs that point to an underlying problem or not.
Logs:
Upload description: arandomuername
Additional information:
Reproduction steps:
Possess a fully charged phone and observe the phone’s non-warmness to the touch
Begin playing music and after a few songs, then notice the phone is warm and the battery
is almost <10% of its previous state
Thanks for the response! I have done as you suggested and will continue to monitor.
One thing I believe could be impacting is a smart playlist i created that would mimic the behavior of d-sub’s temporary cache of songs. This was created before i gained knowledge of the implementation of the rolling cache that’s currently present in symfonium. I have removed the playlist.
You also mention slow queries. I have a library with about 400k songs and noticed variable sync times ranging from 2-4 hours. I haven’t synced with the provider since 11/17 and toggle the media only available offline when I know I’ll be on mobile data. Is there anything I can do to mitigate the queries responses?
Fair enough, I guess I’ll retest when I update to a newer phone model and mess around with the machine navidrome is on. The battery usage is about the same after cleaning the internal state. Love the app overall and appreciate the prompt responses! You’ve fielded all my concerns in the interim!
As requested, I uploaded a new log using the identifier ‘arandomusername’. I did the clean up twice as I noticed a lot of my settings had been reverted to its default state.
I didn’t reboot it actually. I was playing music two days ago and it fully drained the battery so I didn’t think another reboot would make much of a difference. Thinking back on that day, my phone, which has grapheneos installed, was stuck in a reboot cycle off that emptying of the battery. Whenever it would turn back on, while charging and upon the first unlock, the system would boot up all the startup apps to include symfonium then it would freeze and reboot (the battery % said 0 with the charging symbol). I had to turn on airplane mode and force kill all apps manually in between the reboot cycles in order for it to stop and charge without crashing. This may have been when my settings were reset possibly. Not sure.
The phone may have issues really not sure, but this is the first issue I have had with a really warm phone while playing music. For instance, while typing this response I had the app open, not playing any music. Cold to the touch. After one song and into a second song played from the ‘Song Mix’ button with no other apps running in the background, the phone is warm and lost ~4% battery.
On a side note, the performance may be slow from your standpoint, but I have been extremely impressed with the searching capabilities of my library and its speed in comparison to d-sub.
Ho yes the very slow queries are internal ones to updates states when something is played or a resume point is made and it needs to update all playlists.
Those are very specific and adding the necessary indexes would takes a ton of space for nothing but still I don’t see how it could make the device warm and use tons of battery.
Last thing to get more insight would be that you upload a full Android bug report to https://upload.symfonium.app
CPU usage from 402217ms to 102082ms ago (2024-11-21 12:17:12.751 to 2024-11-21 12:22:12.885):
48% 12003/app_process64: 36% user + 12% kernel / faults: 10699 minor 63 major
5% 1636/system_server: 3.6% user + 1.4% kernel / faults: 25228 minor 831 major
3.2% 14121/com.github.catfriend1.syncthingandroid: 2.5% user + 0.7% kernel / faults: 248810 minor 158 major
1.6% 9585/app.symfonik.music.player: 0.8% user + 0.7% kernel / faults: 407 minor
So Symfonium does not seems to be using a lot of CPU at all. Only thing strange is about downloadmanager but I do not see any downloads.
Do you have a lot of automatic offline cache rules ?
The only persistent cache rule was ‘Automatic offline caching of favorites’. I believe I had all those were downloaded at some point, but when my settings were changed that rule was removed and the smart playlist ‘Recently Played’ was the only offline cache rule. This changed the ‘From auto rules’ amount in the Manage offline files tab from ~10+GB to 543MB even though the favorited songs are still available as offline media. I have changed the settings to reflect only the caching of favorites and it is now I guess redownloading them while the ‘From auto rules’ quantity is increasing.
A new project released today which prompted me to sync with the provider finally and it was only 16 minutes in total! So there’s been some measure of progress perhaps from the internal cleanup.
Recently played offline cache is downloading the media after playback, if you enable playback cache and copy from cache to rolling cache it’s not done twice and much more efficient.
That’s what I figured and deleted the auto rule for that playlist.
Also, I am summing up this issue to the wear and tear of the battery. As a test I installed some resource hungry applications and doom scrolled. The drain rate was significantly worst. I’ll just keep a power bank nearby for particularly long distant travel days. Thanks again for this wonderful app!
