Crericper

@RBEmerson, it was a thread that checks play service, but went into infinity loop, and I think, it is most likely caused by play service not responding. Quotes here:

Bravo!! 🎉

Glad to see it finally had worked out!!! 😄

This is the log for pa launched at 'Folder'. I logged this with the same steps performed as before. But this time pa did not wait for any kind of weird thread. alogcat.2019-11-08-07-41-10+1100.txt

1. Switch to PA, with a playlist loaded 2. Go to next song using the main interface, not the notification interface (note: actually playing a song is not required) 3. Switch to OS monitor or SystemPanel (or any other app) 4. Notice that Poweramp CPU usage increases and stays high, specifically that it maxes out a single CPU core @maxmp, have you got the bug successfully reproduced on your end? Or is that the case where the bug only applies to only me and @dinfinity?

Ah, forgot to post my device & info. In case if you need @maxmp. Model: Xiaomi MI 6 Android: 8.0.0 ROM: MIUI 10 9.3.21 Beta Security patch level: 2019-04-05 Kernel: 4.4.78-perf-ge57b3e5 CPU: Snapdragon 835 8-Core @ 2.45GHz RAM: 6.00GB Avaliable Storage: 9.37GB Poweramp version: v3-build-852-arm64-play SHA-1: 3dfe11e642d0cdc8cb2941198f732ca2007e93e3 Unlocker version: 3-build-301 SHA-1: e9e324843197257366074a3027eda6ed3adf5f25 @dinfinity, I believe that's the case as well! That instance have also appeared in the first log I've posted. (Notice there's the orange chunk below.) Here quotes:

After some extra digging, found this: Seems like it is waiting for a thread to stop: "awakenReason":1,"stack":["java.lang.Thread.join(Thread.java:1268)","com.maxmpz.audioplayer.player.PlayerService.onDestroy","android.app.ActivityThread.handleStopService"... As:

@maxmp, sorry that the developer logging wasn't functional on my phone. But you may still find this useful. Information below will be based on the log made by rs.pedjaapps.alogcatroot. I've reproduced the issue 3 times for logging, each time I ensure CPU goes up before continuing. 1. Start Poweramp 2. Swipe for next song 3. Switch to SystemPanel and wait 4. Switch back to Poweramp 5. Repeat step 2-4 two more times Then I've filtered the log with keyword "maxmp", which should only return Poweramp related instances. Here's a screenshot of the filtered & formatted log. I circled everything related to the suspecious "dsp_thread". I have also included a text-based log. Hope you find this useful, thanks! alogcat.2019-11-07-14-24-07+1100.txt

Quick update: Via @dinfinity's new method, I've got the issue reproduced consistantly out of 5 times. This discovery made contribution to log quality as less instance means cleaner log.

To determine CPU usage, you can use SystemPanel. For rooted users, it will show CPU usage for each process individually. For non-rooted users, you probably can determine system load change by using it, but it is very unresponsive and hard to see. So, I'd recommend either go for a temperature change or a battery current change, which can be monitored via lots of apps (including SystemPanel).

@RBEmerson, @Moho Miner, @qwqwas1122, @krazzyvishal Can you confirm if @dinfinity's method also applies to you guys? And everyone else upcoming please do so as well! This can be very helpful in determining the cause of the problem. Thanks.

I've reproduced the bug twice and logged it with LogcatX. Inside this screenshot, the selected 3 lines seems suspicious. Log_2019-11-01_22-09-24.zip

I have successfully reproduced via your steps, with everytime successful. Please take a look at this thread again @maxmp. Screenrecorder-2019-11-01-22-19-27-234[20191101-222630].mp4

So you don't use any built-in / non-file-based playlists? For me, I only use the built-in playlists. Well, that might say playing songs from any type of playlist could've got a chance to drain the battery. Anyone found different situations?

Glad to see some progress on this. For the playlist, is that filebased or non-file-based?

Some new discoveries about the issue on the newer versions (849 in the past days): - seems like charging will also trigger the issue - when the issue occurred, it always use a maximum of about 12.5% of CPU. which is 100% load in terms of single core.

Hi, @maxmp. Have you checked out the log I've posted? Here it is:

SystemPanel Works on both rooted or non-rooted phones. You may need autorun & usage access permission in order to record history in background. Package name: nextapp.sp

Another day on battery draining...

New discovery: CPU went high when sleep timer is finished. (in custom pa playlist) This time not as high as the previous reports. CPU only went to 12%(1.9GHz), but still is abnormal for idling. The phone was cold during playing, but becomes warmer immediately after sleep timer has reached. (Logcat included) Log_2019-10-26_01-30-01.txt

For me, I have no file based playlist, but sometimes play songs from Folder. As you've probably thought, I did not encounter this issue on every session.

Seems like you are right. The issue reappeared. There must be something wrong with Poweramp. I think it may somehow to do with the sleep timer. Since in the log below on Saturday, at that time I was sleeping.

Have you tried to turn off the Chromecast button? The issue didn't occured again for me after I've turned off that option. You may scroll up and take a look at my previous posts for more detailed information about this bug. EDIT: The issue reappeared.

Here're some updates for the High CPU Usage / Battery Drain problem. Make sure you've read the message at the top of the thread before posting.

I think you might be right on targeting the Chromecast button cause I've got it enabled as well.