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?