High Battery usage

[Enigma1309]

Steps to reproduce the bug

Listen to music

Expected behavior

Moderate battery usage

Actual behavior

High battery Usage

Screenshots/Screen recordings

Here is a quick ChatGpt response.

Android SS

Logs

No response

ViMusic version

v0.6.2

Android version

Oreo (8.1)

Additional information

After permanently switching to this repo i've found that the app uses way more battery then it should also it uses a lot of resources as compared to official app. Yeah there are some features implementations beyond the official app but the battery usage is a lot as compared to other apps.

Probably there's some background process recurring again n again.

[25huizengek1]

Can you describe what you were doing during this hour of active use? Because if you were listening to music I think this is kind of normal: the app is actively downloading, transcoding, caching and playing (possibly even post-processing, think of skipping silence, normalization and bass boost) music and updating statistics, which can be resource-intensive. And if the screen was on during that time the battery is also being used for rendering the UI, so those are all factors that could cause this.

[Enigma1309]

i was inactively listening to it by keeping my phone on side (screen off) and doing other chores...and listened probably 3-4 songs watching the lyrics keeping the screen on...

(think of skipping silence, normalization and bass boost)

I've all those features turned off cause i like to listen raw music...anyways

---

Though,writing cache maybe one of the reasons of high battery consumption. But i've not experienced this issue before on the upstrem repo. i maybe wrong tho..

[25huizengek1]

Apparently (I haven't conducted any tests myself though) these numbers are pretty normal, at least according to this thread.

[Enigma1309]

at least according to this thread.

that thread is almost 13 years old, a lot of things have changed since then

I haven't conducted any tests myself though

Okay let me do this job myself 😀

adb shell top (for this app, while playing a music (screen on) )

and

(CPU usage are skyrocketing)

---

adb shell top for this repo(https://github.com/ShareASmile/ViMusic, kinda same as official but with different app id..)

(better cpu and ram usage overall)

I think there's some loop in the code that causes the cpu usage to skyrocket, i was also surprised to see this behavior for the first time..

[Enigma1309]

CPU usage is still high is not playing the music, just app opened ideally

[25huizengek1]

Most of this usage was caused by multiple (apparently really expensive) snapshotFlow calls in the PlayerService (apparently it causes a lot of useless thread creating and thread parking to occur), which was fixed in d1b4ed1a0eb4c8bfb891e8fc9d8add58703840bd so please let me know if this fixes it. In my emulator the app goes from 45% usage in idle state to actually 0%...

[Enigma1309]

I think i have to wait for the today's nightly build...btw that all scanning was done on actual hardware device using adb.

[25huizengek1]

What are your (@Enigma1309) experiences currently, has this fixed it? I could not find a needlessly expensive call anywhere else, so this must have done something to your battery usage.

[Enigma1309]

Ther

Foreground :-

• After :-

Background :-

• Before:-
• After:-

I see foreground and backround cpu usage has 'decreased' a bit : ) , the decrease isn't too much, but i need some more time to see how i affects my battery in daily usage

[Enigma1309]

Okay Turning off wavy seek bar decreased the foreground cpu usage (all the above comments are made when the wavy seekbar was on)

After turning off wavy seekbar

[Enigma1309]

but still it's way off from the official app even in foreground mode 😓

[25huizengek1]

I don't know how you manage to record those numbers, to put this into perspective: I use ViMusic daily, today for example I've listened for a total of 4 hours, 2% battery usage (on a 5000 mAh battery), with battery optimizations turned off, and the app idles for me on 0% cpu usage. When I start the playback, according to the profiler almost all usage comes from UI (Compose) and playback (Exoplayer).

And even on an avd in debug mode idling in the app with the screen on looks like this (only the UI is not continuously sleeping):

In order to try and resolve this issue though, I think we should conduct proper tests (with more than a single sample) across versions (upstream ViMusic, the latest release and the latest nightly build). I'll try to get some data in a few days.

In the meantime though: I'm curious what device you are running this on. The measurements I get are of course relative to the specs of my device (cpu and battery), and not yours.

[Enigma1309]

I'm Using Motorola Moto G4+ with the stock android oreo 8.1

I've compared these numbers with upstream repo in this comment I'm using adb on my pc to check the real-time memory/cpu usage on my phone.

If this was really a device issue then the upstream repo would also show this same behavior but it isn't.

I'll try to get some data in a few days.

i hope you do, but the main problem i'm suspecting is, maybe the swipe gestures but i'm not sure though.

Earlier i was suspecting the local files to be the issue then, I've tested the apps with local files permission turned off then also it's showing the same behavior so it isn't the issue.

[25huizengek1]

I was not implying that it is a device issue, but I was rather interested why your numbers are so much higher than mine.

[25huizengek1]

The swipe gestures are definitely not it, that code is not even run when nothing is swipable on the screen at that moment, and suspends when the items are not pressed.

[25huizengek1]

I think a lot of the issues got fixed in the last few days, so I guess we can close this now?

[Enigma1309]

okay...I saw a little bit of performance improvement and still can't find the actual performance drag...

[Enigma1309]

Here's the recording if you want (see opening the player causes this issue too even if not playing)

https://github.com/25huizengek1/ViMusic/assets/94917588/5ea0dd86-e0dd-40f4-a23c-8258871f9b07

[vedxp]

Experiencing the same, here's the battery usage of this fork of ViMusic compared with Innertune. The battery consumption is literally double in only 1/2 of the usage time as compared with Innertune.

[Enigma1309]

Hey @25huizengek1 latest version almost solves this issue until i enable wavy seek-bar

Ideal cpu usage :- 10-50 (usually stays around 30) Ideal cpu usage (wavy seekbar enabled) :- sometimes peeking upto 100 👀

Thank you so much with the feature implementation ️❤️ , for now i'll turn off wavy-seekbar.

almost solves this issue

i said this because i can see some lag introduced when opening the playlist view while a song is playing see the video below

https://github.com/25huizengek1/ViMusic/assets/94917588/0e137723-a69c-4812-823d-6060d1b1ed49

Apart from it the net battery draining problem is almost gone...

Thank you ❤️

[dtomvan]

Wavy seekbar was never meant to be optimal, though. You can either use the static wavebar or we could have a performance-focused in-between alternative, like a since wave which isn't animating on every frame...

[25huizengek1]

@Enigma1309 This is probably because of the fact that the wavy seek bar rerenders when the player reports a new position, and on each render calculates a sine function for every pixel. I guess this could be a bit more efficient, maybe we should just provide a 'wavy seekbar quality' setting, as the path function already supports this, we could expose it to the user.

Some simple measurements on an avd:

Quality: every 1 pixel

Quality: every 10 pixels

Quality: every 40 pixels

Static seekbar

There seems to be another bottleneck, though, so I'll try to profile this later.

[25huizengek1]

In the last few commits, I've removed all but one snapshotFlow calls, which solved a lot earlier on (these calls are really expensive) so I think the only battery issue we have left is with the wavy seek bar?

[25huizengek1]

@Enigma1309 Can you please look at today's nightly build? In my experience, all battery drains got fixed. If you really want to squeeze out more performance seek bar quality is of course always an option. adb shell top gives me promising results, so I'm curious what your findings are.

[Enigma1309]

Yes battery draining issues got fixed for playing songs but it is still present when opening the playlist view (swiping up to see currently queued songs), the cpu usage gets high for just opening the view, Also opening playlist still causes the jitter/lag (as mentioned in the previous comment above), apart from that major battery draining problems are solved 👀

[25huizengek1]

Great! Do you have any additional information on this last problem? I'm unfortunately clueless on this, except for the fact that the queue is just a large list with images, gestures, reordering/swiping state for every song. This should not justify a big leap in battery usage or major lag though...

[Enigma1309]

One of the reason is this..

When paused:-

But those above are the minor cases ( I just checked this existed in the upstream version too ), the real cpu spike happens when opening the playlist drawer, it is for a minute second but this causes jitter in opening and closing the playlist, this makes app feel kinda sluggish.

I checked it with the neomusic fork (it is upstream with a little yt tweaks but with different app id so it doesn't conflict with your app)

https://github.com/25huizengek1/ViMusic/assets/94917588/1e13bdcc-80c2-4ca0-90e3-77d8c40855e7

(This also happens if we swipe, i showed by click to avoid threshold bias)

[25huizengek1]

This commit (47897862fef8e6b81a1a72d811ccb51acfadaea7) should fix the lag spike. The visual lag spike is not visible on my test devices, and the RAM and CPU usage peak is way flatter than before, the peak that remains is caused by image loading when opening the queue.

Can you please check if this is the case for you as well?

[25huizengek1]

While profiling I unfortunately couldn't measure any other performance/recomposition/lag issues though.

It's also probably worth noticing that although the implementation has changed, there are no visual changes (the bars look identical to vfsfitvnm's implementation)

[SiddhantRakh]

@Enigma1309 Can you please look at today's nightly build?

Unrelated, but where can I find and try these nightly builds?

[Enigma1309]

it's on fdroid

[25huizengek1]

@Enigma1309 Can you please look at today's nightly build?

Unrelated, but where can I find and try these nightly builds?

You can download these builds either directly from the repository or add https://25huizengek1.github.io/fdroid-repo/fdroid/repo/ to your F-Droid client.

[SiddhantRakh]

@Enigma1309 Can you please look at today's nightly build?

Unrelated, but where can I find and try these nightly builds?

You can download these builds either directly from the repository or add https://25huizengek1.github.io/fdroid-repo/fdroid/repo/ to your F-Droid client.

I have already added the repository to my F-Droid client as suggested by @Enigma1309 . I am quite surprised how optimised the nightly builds are. I am also enjoying using the AMOLED theme you just added into the app (nightly build). Thank you.

[Enigma1309]

This commit (4789786) should fix the lag spike. The visual lag spike is not visible on my test devices, and the RAM and CPU usage peak is way flatter than before, the peak that remains is caused by image loading when opening the queue.

Can you please check if this is the case for you as well?

I've just checked the nightly build but unfortunately the problem still seems to be present 😐

[Enigma1309]

https://github.com/25huizengek1/ViMusic/assets/94917588/24f34b96-8a82-417f-8241-527086ee037e

Unfortunately the problem seems to worsen even more 😅

[25huizengek1]

2024-02-25.10-15-15.mp4 Unfortunately the problem seems to worsen even more 😅

That... is just straight up impossible 😂 The player is paused, so the MusicBars composable is not even called, so unfortunately that means there is another rendering/lag issue. sigh...

[Enigma1309]

hope it gets better and fixed

[25huizengek1]

I did find something new though: I have had rewriting part of the theming code on the schedule for a while now and finally decided I should go for it. I pretty much got it working like it had worked before. The only thing I’ll have to tackle is the dependency on MonetCompat, as it heavily increases the APK’s size, while I don’t even need 99% of the functionality, but that’s beyond the scope of this issue.

What I did find though, is a lot of unnecessary memory usage and recompositions, which for example has resulted in a stupidly laggy player bottom sheet animation. I’ll push the changes later today when I have the time to. It should improve the dynamic theme performance, the theming memory usage/performance altogether, and a lot of unneccesary lag (when skipping to the next song, for example)

[Enigma1309]

i'll be waiting to test the release when it comes out, btw thanks for maintaining this repo ❤️

[25huizengek1]

No problem. I really like working on the project, especially because I daily-drive ViMusic myself. Thank you for your appreciation!

In about 22 minutes a nightly build will be triggered, so please let me know what you think.

[Enigma1309]

Things have improved but they are not as good as the original one, btw i,m loving the dynamic theme changes 🫶

https://github.com/25huizengek1/ViMusic/assets/94917588/0603a7fb-b827-413e-b17a-7ca3c5f7e6af

also sometimes the liked music is shown as not liked or vice-versa in the notification though it's not a big deal

[25huizengek1]

I was already aware of the notification issue, but I just absolutely hate dealing with all of the edge cases that come with notification actions and I thought I got it right, but unfortunately it still needs tweaking.

The performance issue is also still not 100% there, but I'd say that since the last commit the theme at least gets applied faster and the player animation is not as laggy as before, but I guess there is still room for improvement.

[25huizengek1]

Looking at the queue though: I noticed that the lazy column could use some optimization, so now it feels even smoother, at least for me. I cannot reproduce the lag you are still experiencing anymore.

[25huizengek1]

I guess we can close this now?

[Enigma1309]

yeah i think we can, although i've moved the dynamic theme problem to a new issue