Jump to content
Poweramp

dinfinity

Approved Members
  • Content Count

    16
  • Joined

  • Last visited

About dinfinity

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Also haven't encountered this issue again even though I've used PA extensively. /thread indeed! :-D
  2. First tests are positive! I can no longer reproduce the issue! Thanks @maxmp for the fix and @Crericper and everybody else for the information and cooperation on this issue!
  3. @maxmp: That is great news! I look forward to not reproducing the issue with the new build!
  4. @maxmp: Sent you the bug report. I suspect this is the culprit: "player service thread" prio=5 tid=9 Suspended | group="main" sCount=1 dsCount=0 obj=0x12c07340 self=0x7f78b8fc00 | sysTid=21390 nice=0 cgrp=bg_non_interactive sched=0/0 handle=0x7f7618d3a0 | state=S schedstat=( 0 0 0 ) utm=3765 stm=66 core=5 HZ=100 | stack=0x7f7608b000-0x7f7608d000 stackSize=1036KB | held mutexes= at ׅ.tg$D.D(":702) at ׅ.tg$D.ׅ(":696) at ׅ.tg$L.ׅ(":759) at ׅ.tg.ׅ(":645) at ׅ.px.release(":5034) at com.maxmpz.audioplayer.player.PlayerService.llll(":3093) - locked <0x014f9035> (a java.lang.Object) at com.maxmpz.audioplayer.player.PlayerService$v0.ׅ(":1145) at ׅ.pz.handleMessage(":29) at android.os.Handler.dispatchMessage(Handler.java:102) at android.os.Looper.loop(Looper.java:148) at android.os.HandlerThread.run(HandlerThread.java:61) (utm is high and this seems to be the only thread that is not waiting/native waiting)
  5. @maxmp: Forgot to post this info. v3-build-852-arm64-play [852004-ce3a07c4] Full Version 64 bit
  6. Nice work! com.maxmpz.audioplayer.player.PlayerService.onDestroy would be the significant bit here. The application generating the log seems to be a MIUI monitor app, but it still gives valuable information about PA. Looking at "beginTime":3210750," and endTime":3214770", it seems that the MIUI monitor gives off a warning because the onDestroy method is taking more than 4 seconds. This is probably because something in that onDestroy method is stuck in an infinite loop as hypothesized before.
  7. @maxmp: Device: Blackberry Priv (STV100-4) Android 6.0.1 Security patch level October 5 2017 (Thanks, Blackberry) Kernel 3.10.84 I will submit the report later today!
  8. Good initiative. Reliable reproduction of an issue is the most important thing towards solving it! As an addendum, I noticed that playing isn't even required to get the behavior. The updated reproduction instructions are: 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: I'll gladly run a development build that outputs a lot of debug logs to logcat to help pinpoint the source of the problem. @Crericper: Perhaps you can doublecheck whether playback isn't required for reproduction for you as well.
  9. Good to see that the reproduction instructions lead to the same result in your case, @Crericper. Thanks for the video showing the pattern as well. It seems fairly obvious that some background PA thread gets stuck in an infinite loop when PA is paused (or stopped). When I dove into my logs the previous time around, I also found that those dsp_thread calls coincided with PA being paused, but I don't really see the connection with the playlists (yet). It may just be that the failing thread is spawned very near these calls. IIRC, these calls are also visible when the problem does not occur on PA being paused. The logcat results may be a red herring here. Addendum: I tested a bit more with a non M3U, normal playlist and that also leads to the issue reliably. I tested various other options from the Library ('Folders', 'Folders hierarchy', 'All songs') and the issue only occurred the first time after the issue had occurred with a Playlist, even after killing PA, so the issue seems to arise when PA starts in a Playlist (this explains the 'first time' issues) or when a Playlist is loaded after PA is opened. Loading a Playlist at any time in PAs lifecycle seems to set it up for the problem occurring on PA pausing. Edit: With paused I mean as in the lifecycle of the app, not pausing playback.
  10. I can confirm that I also generally use m3u(8) playlists when the issue occurs. I did some testing with playback using an album selected via the Library 'Album' option and the issue did not seem to occur, which is good news. I see that others see the same pattern I'm seeing. Let me repeat my reproduction instructions: Note: pausing using the notification interface keeps Poweramp alive and does not lead to the issues. Pausing via the main interface and then switching away does not keep Poweramp alive (in the same way).
  11. Alas, the update also does not solve my battery drain issue. The workaround I now use is to pause songs via the notification interface so that the notification interface does not disappear. This prevents PA from shutting down and going into the battery draining loop.
  12. Addendum: Before installing this build, I've actually seen PA go to 75% continuous usage. With this build, I can fairly reliably keep increasing PA usage in the same way: 1. Switch to PA 2. Play song 3. Go to next song 4. Pause 5. Switch to OS monitor 6. Go to 1. Usage either increases with 25% (about 2 seconds after switching to OS monitor) or does not increase at all. Did this about 6 times, and Poweramp is now using 95% CPU. Killing Poweramp puts it back to 0% again. I'm a developer myself and will happily cooperate if you want logs or other information.
  13. Not directed at me, but I just installed this build. Same behavior as I reported earlier. Second time pausing and pushing PA to the background and OS monitor now shows PA using 20% continuously, so it does not seem to be related to Google Services in my case.
  14. I've had this issue for a couple of months as well. Tried downgrading, autoscan off, etc. For me the PA behavior seems to kick in sometimes (maybe 1 in 5 times, same file) after I pause a song (or when I unplug my headphones), which leads me to believe there is some kind of race condition involved. The behavior on my phone is that PA will be shown using 20-25% CPU (almost) continuously in OS monitor. Additional info is that I have also seen it stuck at 45-50%, which might indicate two threads operating in the same way (stuck in some loop, probably). Killing/resetting PA with OS monitor resolves the issue. I can't see anything particularly significant in logcat. The lines closest to when high CPU usage kicks in seem to be these: 07-23 21:49:17.407 30969-31212/? I/dsp_thread.c: dsp_thread_release_impl releasing: com.maxmpz.audioplayer/plugin.tempo 07-23 21:49:17.407 30969-31212/? I/dsp_thread.c: dsp_thread_release_impl releasing: com.maxmpz.audioplayer/plugin.reverb 07-23 21:49:17.407 30969-31212/? I/dsp_thread.c: dsp_thread_release_impl releasing: com.maxmpz.audioplayer/plugin.milk Sidenote, I've also noticed these logcat lines when editing reverb and tempo settings in PA: 07-23 21:44:03.867 29657-30677/? W/MilkRendererJava.cpp: avg frame time us=3389 avg fps=59.986286 Blackberry Priv, Android 6.0
  15. Phone is (Dutch) HTC Desire Z (Virtuous 1.0.1 Custom ROM (Android 2.2.1) (and many more customizations). Side note: the tracks (with large embedded album art) do start playing, it's just that most controls are dysfunctional while the image is decoded. Sample track will be emailed asap!
×
×
  • Create New...