Database Users

Nook Battery Usage

Hi...
So, I've opened up Nook Color Tools and clicked All Settings in order to find out more about my Nook.
Are these findings normal?
Attached scr...
The battery seems to drain quite quickly too, yesterday I've fully charged it, now this? Using wifi all the time, I've sent some emails with gmail and tried browsing web and failing
Stock 1.1.0, FT1.5-beta5'ed.

From my experience that is normal for a nootered nook. I unrooted my nook and did a manual root and did not install any Google apps, or any other un-need junk. Now granted i have ADB install stuff but my battery life is unchanged. What ever get installed with the Gapps and other just runs the battery use threw the roof.
So to answer you question yes that is normal for the automated roots.

Thread being moved to general.
This is not a mod, ROM or kernel.

I disagree; the issue seems related to nootering. but I could've started this in the nooter thread so maybe you could move this into the MinimalTouch1.5-beta5 thread for I believe it's clearly a mistake - how can there be 70% battery usage of cell standby, if the nook doesn't have a cell radio?
How does this application measure it's battery usage, what is "cell radio" - is it an app, like Phone.apk ?

Is it registered?
If found that my nook only lasted a couple of days unregistered, three weeks ago I registered it, haven't charged it since.

from what i learned what ever nootering does or installs makes android look for cell signal or maybe just try to send signal. I tried all the suggestions i delete the phone.apk plus a dozen others. but what i learned was these apk were always there. the issue was that once you nootered something starts to try to use them or keeps them awake. My battery life was about 3 days.
I tried the registration thing as well.
All i know is i unrooted my nook. then did a manual root. turned on adb wireless. Installed superuser, busybox, then manual installed apps by adb installing them, and my battery life is that of an unrooted nook. I have no Google apps installed. or any of that other junk. I'm not sure which app causes the issue but what ever it is it is part of the nooter not because of it being rooted.

betterbatterystats
rm phone and dialer apks
freeze gapps when not in use and anything else if possible
bad apps prevent sleep - analyse with bbs
all this due to Google's dalvik, which isn't handling wakelocks or enabling us to do it manually. only way is to guess and disable things at the moment. effects all android phones and the main reason why iPhone with its crippled single tasking works better
ciao

Since a Cell Radio doesn't actually exist, there is no actual data for Cell Radio, therefore Battery Statistics displays the wrong info, however the reason your nook is dying so fast if I had to reason based on your screen shots, is because you're leaving your Wifi on which is taking up a good portion of your battery.
Nootering doesn't make the device actually try to use the Cell Radio or any such thing, the stuff has always been there, and if you manually rooted by using a hacked APK and installing nook color tools, you would find that "Cell Radio" still contains the most "Battery" usage despite the fact it's not actually using any battery.
Another thing to keep in mind is when you've used Nooter and installed Gapps and stuff (and you leave your Wifi on) you'll have significantly less battery life, because it's doing all the data updates for Gmail, and any other apps you've also installed. This therefore causes it to use your Wifi more, and waste battery life. This isn't just a "Nook" thing, this is true for all android devices, if you have Apps that need to use Data to get updates, and they're getting the updates all the time you'll find you have significantly less battery life.
Normally on a normal android device we'd have access to Accounts & Settings, which would allow us to access options for setting when Data Sync happens, but on the nook you don't have such options. So therefore they happen (probably) every 15 minutes. This causes your battery life to go down.
To remove the "Cell Radio" from the battery statistics bit you can delete/freeze/rename Phone.apk and TelephonyProvider.apk
Note: This has no affect what so ever on your battery life, it only removes Cell Radio from battery statistics so you get a more accurate reading.
Move them using this:
Code:
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.apk /system/app/Phone.OLD
adb shell mv /system/app/TelephonyProvider.apk /system/app/TelephonyProvider.OLD
adb reboot
To undo this use:
Code:
adb shell mount -o remount,rw /dev/block/mmcblk0p5 /system
adb shell mv /system/app/Phone.OLD /system/app/Phone.apk
adb shell mv /system/app/TelephonyProvider.OLD /system/app/TelephonyProvider.apk
adb reboot

I figured as much, and wanted to share this info here, but you already beat me to it
Nonetheless, like you wrote above, I do not need Phone.apk and TelephonyProvider.apk - there's com.android.phone running in the background which I do not need.
It could however be waking up the device from deep sleep a lot, and it's not necesarily WiFi - B&N claims 3 weeks of WiFi on usage so with background processes, I think I should be able to pull at least a week.
Bear in mind that WiFi turns itself off with screen off, at least that's how it's configured out of the box.
So far, I kicked Phone and TelephonyProvider, will see if anything improves.
ps shows this:
app_31 1218 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
app_31 1220 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
How can I check what app is app_31 ?

imachine said:
app_31 1218 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
app_31 1220 1205 636 328 c0246930 afe0c74c S /system/bin/logcat
How can I check what app is app_31 ?
Click to expand...
Click to collapse
The parent PID of 1218 and 1220 is 1205 (third column).
When you check that it will undoubtedly show /sbin/adbd, the ADB demon.

Random shuts down - Thermal issued ACTION_REQUEST_SHUTDOWN

Some time ago my phone started playing up - I would feel it vibrate in my pocket and would pull it out to check the notification... It was being shut down.
A few weeks went by an this would happen occasionally, then one day after a random shutdown the phone would shut down immediately after booting into the system. Well things has gotten worse, and now these shut down events are frequent and for the last few days my phone has been useless. Like this: http://www.youtube.com/watch?v=LzNO_VVC3zg
When this all started I was on a mainstream custom 4.2.2, and having thought maybe this would be fixed in another ROM I have tried another mainstream custom 4.2.2, 4.3, and Stock 4.2.2 and 4.3 (relocked,fully wiped). Alas my issues were not going away so I had to try fix this, so I tried another battery - no good.
No matter the random shut downs, I had a stable recovery/fastboot to reflash, and the phone was charging when powered off.
So during one of these small periods of time when my phone was stable I set up ADB and started up Logcat Reader. After two crashes and again trying both batteries I had some logs...
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 7 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 6 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 5 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 4 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 3 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 2 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 1 at 79.0 degC
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[0] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[1] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[2] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[3] to 1188000
D/ThermalDaemon(182): ACTION: LCD - Setting max LCD brightness to 181
D/ThermalDaemon(182): ACTION: BATTERY - Setting battery charging mitigation to 3
I/ActivityManager(515): START u0 {act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras)} from pid 515
This being my first look at these things, I look through each of the logs and see what looks like normal battery temperatures (hovering between 30 and 40 degC), but at some seemingly random time we have a 79.0 degC battery and subsequent shutdown.
I have extracted out of \system\etc\ on a few of these ROMs and ThermalDaemon appears to be doing as expected.
[batt_therm]
sampling 5000
thresholds 360 370 380 390 410 420 450
thresholds_clr 350 360 370 380 400 410 440
actions cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery
action_info 1512000+400000000+240+0 1296000+325000000+215+0 1296000+325000000+192+0 1188000+200000000+181+1 1188000+200000000+181+1 1188000+200000000+181+2 1188000+200000000+181+3
At 79.0 degC the values should be set to 1188000,200000000,181 and 3.
So - why 79.0degC if the battery is not hot (faulty batteries? faulty power management IC? some other bug?), and what is the affect of 'setting battery charging mitigation to 3' and what calls the ACTION_REQUEST_SHUTDOWN?
Obviously I have no chance to RMA, but would be happy to resurrect this phone some how.

Could be a software issue within the kernel or worse in a folder such has /dev/ or /persist/.
It looks like a countdown was triggered.
The thermal needs a calibration for sure.
Sent from my Nexus 4 using Tapatalk 4

Well I have tried 2.0, 2.2.2, 2.3 stock, CM, AOKP, trinity, faux kernel and a few others so this very much feels like a hardware problem however the way in which software interacts with hardware could also be at fault. All give the same result - the phone (usually) boots first time and stays online for a while then shuts down. Once the first shutdown occurs, the phone will typically shut down right after booting until a wipe/install is done.
With faux kernel options disabling the default thermal management things seemed a little better for a while but then it shut down again. I have tried logging this, and at least in the first instance it didn't look like the batt_therm was hitting 79.0 degC on this kernel but I haven't identified the cause in software/hardware at this point.

I'm getting this too, but at a lower temperature
D/ThermalDaemon( 204): Sensor 'batt_therm' - alarm raised 7 at 45.9 degC
D/ThermalDaemon( 204): ACTION: BATTERY - Setting battery charging mitigation to 3
Followed by a shutdown.
I/ActivityManager( 723): START u0 {act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras)} from pid 723
I can make the error more likely by running some programs. E.G. rymdkapsel is very effective at shutting down my phone after a couple of minutes playing.
I'm going to dig into that ThermalDaemon code to see what is happening. It may be worth compiling a new one a cutting out the sensor alarm behavior to see if that stop it, to show whether or not it is that code that is in the failure path.

David_Johnston said:
I'm going to dig into that ThermalDaemon code to see what is happening. It may be worth compiling a new one a cutting out the sensor alarm behavior to see if that stop it, to show whether or not it is that code that is in the failure path.
Click to expand...
Click to collapse
I think I chucked the system board for this phone after buying a replacement (broken screen) nexus 4. Good luck with your testing and do report back.

Maybe I can block it here..
muzzl3 said:
I think I chucked the system board for this phone after buying a replacement (broken screen) nexus 4. Good luck with your testing and do report back.
Click to expand...
Click to collapse
I changed all the shutdown actions in the thermald config to 'none' to no effect. It still shuts down randomly.
I changed the battery to a new one to no effect.
So I got myself the cyanogenmod sources and started searching for things that might be issuing the request.
frameworks/base/services/java/com/android/server/BatteryService.java looks like the culprit. It has two methods shutdownIfNoPowerLocked() and shutdownIfOverTempLocked() that issue the request. Also it waits until the system has booted before it issues the request, which fits with the pattern of it fully booting before shutting down on the times that it shuts down right after powering it on.
I'm rebuilding form source, which is taking all day. Once that is done, I'm going to set the user confirmation flag in the action request to see if this is the code in the failure path. If so, that doesn't explain the cause, but it provides a way to block the effect and then trace back to the cause.

Success..
It's the shutdownIfOverTempLocked() routine that is firing and shutting down the phone.
I changed the call to require a user acknowledge so it would not actually shut the phone down and I added a log to see which one was causing it..
[email protected]:~$ grep shutdownIf logcat.txt
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
So the temporary fix is to change 'false' to 'true' in line 339 of BatteryService.java and recompile android, or just BatteryService.java if you know how to do that in isolation.
I presume it's a sensor problem. I'm going to dig in and see what is causing it to fire on this condition and see if there isn't a software mitigation that can be put in place.

Am I the only one who would not try to mess with a phone that raises a battery temperature alert?
Especially with lithium batteries I would not touch that thing again.

Well. Trust me, I'm an engineer . Actually I'm an engineer who spent part of my like designing LiIon and LiPoly charging circuits for cell phones and I'm not at all concerned.
1) The thermal sensor is returning bogus values. If the values are bogus, the thermal overload clearly isn't working with or without the patch. So if there was a problem, thousands of affected users would be at risk.
2) The battery isn't hot. It's cold.
3) You can't make these things burn. I've tried. The ones that burn have faulty manufacturing.
4) A burn scenario is a runaway reaction, there's nothing the software can do about it one way or the other.
5) I don't believe it's the thermal sensor. Thermal sensors don't just break like that, especially uniformly across so many devices. I've changed the battery and it carried on - the sensor is in the battery. The problem is in the phone, not the sensor.
---------- Post added at 06:28 PM ---------- Previous post was at 05:57 PM ----------
thermald looks at a number of temperature sensors, including the battery sensor and the configuration file tells it to shut down on several of the sensors when they hit a max. However thermald does not issue shutdowns for the battery thermal sensor limit. It implements the clock throttling at different temperature points, the idea being that the battery will never get to the max temp.
So when the thermal sensor erroneously reports a max temp, thermald raises all sorts of alarms that you see in the logs and slows your clocks, but it does not shut off the phone.
The code that shuts off the phone is in BatteryService.java and BatteryService.java gives you no logs whatsoever when in does what it does. The logs above are what I added and it happens once for each time the phone erroneously tries to shut down.
So it's easy to see the alarms in the log, see the shutdown happen and conclude that thermald is doing it, but it isn't. BatteryService.java is doing it and is being stealthy while it does it.

I would link to my android image with the mitigation but this web site isn't letting me include urls.

I experienced the same problem on a Nexus 4.
I replaced the screen myself, the phone updated to 4.3 shortly after and the problem started to occur. I rooted the device and installed CatLog, and I get the same sequence of messages: batt_therm reports 79.0°C, raises all the alarms, and then the shutdown command is issued - but the device isn't hot at all. It also happens just after the device boots. This behavior seems unpredictable, and isn't related to real temperature - making the device hot doesn't make the problem more or less likely to occur. I bought a new battery from an LG vendor and replaced it, but the problem is still here, so it doesn't seem to be a component failure.
Did you made any progress during your investigations?

eva03_sp said:
I experienced the same problem on a Nexus 4.
Did you made any progress during your investigations?
Click to expand...
Click to collapse
I too had this issue. Stopped using my nexus 4 for more than an year due this random shutdown issue.
A few months back I was recording logcat and found that battery temp is reported as 79C and eventually that is triggering a shutdown. But the battery and device is chill cold. Tried several custom roms and kernels and changed the thermald thresholds etc etc. But nothing helped. Could not find any fix to suppress this. and kept the device back in the shelf. When I wanted to get rid of nexus 4 to get a new one.. I thought of giving a final attempt to fix the issue. Found this thread.
Here is how I fixed it.
1) Installed latest cyanogenmod rom (stock rom is also fine.. but need to deodex and odex back)
2) extracted the services.jar from /system/framework folder to my PC.
3) downloaded the smali.jar and baksmali.jar from this post (//forum.xda-developers.com/galaxy-s2/themes-apps/how-to-manually-deodex-odex-t1208320)
4) extract the classes.dex file from the services.jar
5) java -jar baksmali.jar classes.dex (seep the dex file in same folder as the baksmali.jar)
6) this generates an out folder. with the smali files. Look for BatteryService$3.smali file
Look for..
__60 .line 298
__61 new-instance v0, Landroid/content/Intent;
__62
__63 const-string v1, "android.intent.action.ACTION_REQUEST_SHUTDOWN "
__64
__65 invoke-direct {v0, v1}, Landroid/content/Intent;-><init>(Ljava/lang/String V
__66
__67 .line 299
__68 .local v0, "intent":Landroid/content/Intent;
__69 const-string v1, "android.intent.extra.KEY_CONFIRM"
__70
__71 const/4 v2, 0x0
FIX A)
At Line 71 -> replace 0x0 with 0x1
This change when implemented, will make a dialog poup before shutdown. You can click on cancel to avoid the shutdown.
FIX B)
But if you don't want that annoying dialog, and just want to avid the shutdown silently.
At Line 63 -> replace ACTION_REQUEST_SHUTDOWN with ACTION_BATTERY_OKAY
You dont need to modify line 71. You have to keep it 0x0
6) Once the smali file is modified compile the dex file back using the below command
java -jar smali.jar out -o classes.dex
Make sure the out folder has all the files including the modified it their exact locations
7) Now use winrar to open the services.jar and drag drop the new classes.dex file into it.
WINRAR will ask if you would like to replace the classes.dex file. Choose YES. Also in the compression mechanism choose store.
8) Now copy the services.jar file back to the phone. First keep it in /system. NOT /system/framework. and using a root file manager first set uid and gid to 0 (root) and set the permissions rw-r-r
9) NOW move to /system/framework folder.
10 That's it. Reboot the phone and enjoy the fix.
I tried out FIX A. I am seeing it action.. Simply cancelling the dialogs for now. If I can't bear that annoyance any more I'll try the FIX B.
Hope this helps.

Hi,
You saved my life. really I had the similar issue with my Samsung TAB PRO. shutdown when sleep.
I was lost for month until i found your Post here in XDA and followed your instructions and resolved the issue!!
My process must have changed - slightly.
https://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/rom-7-1-xsm-t900-unofficial-cyanogenmod-t3524853/post78826518
So many thanks for detailed professional explaining and description.
Robert

Lag or Freezing on any CM base?? logcat here!

So.. I've been experiencing a 'not so unique' problem on any AOSP/CM/PA rom.
Everything is great. I rooted my brand new S4 L720t. And put my favorite rom on it. (Based on CM source's as always) and proceeded to install my apps and such like turning on/off settings I do/do not like. Again all is well until i start said application. (Mostly games or heavy ram intensive apps. But not always.) I play pocket legends. And 5 minutes after.. (in the middle of a ram intensive fight) freeze. Complete lockup.
So I needed yo know if this was a rom issue. No. As many roms as i can find exhibit the same. Even pure CM/AOKP.
At this point I assumed ram. Nope. Stopped all bg apps and still no fix. So next would be kernel.
So i flash kt747. No. Cronickernel. Nothing. Still freezing. As I'm typing this ive suffered several freezes (4 to this point).
Hail Odin! Nope. Still there!! Im freaking lost.. and looking back at stock tw.... eeeeeewww! :'(
So.. here i am.. freezing on any rom i can flash.. and i pulled a logcat and replicated the freeze. And got results! But... alas.. I'm completely noob to dumps...
Please.. someone that CAN read dumps and logcats.. please point me to the problem.. and then i can find a fix.. ir if you've got time and stuff.. maybe WE could.. lol..
Sorry to ramble... like to logcat... http://pastebin.com/hiKZBk8s

I've narrowed the logcat to...
E/TemperatureHumiditySensor( 743): mCompEngine is NULL
I/Choreographer( 1134): Skipped 778 frames! The application may be doing too much work on its main thread.
I/Choreographer( 1134): Skipped 65 frames! The application may be doing too much work on its main thread.
I/ActivityManager( 743): START u0 {act=android.intent.action.MAIN cat=[android.intent.category.HOME] flg=0x10200000 cmp=com.tsf.shell/.Home} from pid 743
W/Launcher( 4352): setApplicationContext called twice! [email protected]
Also kinda a bump.. lol

Device occasionally becomes completely inresponsive while screen is off

Currently ripping my hair out over this. I have a very annoying problem with this S7 Edge which at random intervals, usually once a week or so, becomes completely unresponsive while the screen is off. Meaning that you can't turn on the screen or do anything other than a force reboot. Calling the phone works as in the caller hears the dial tone, but the Edge doesn't react at all. Have tried a complete factory reset, didn't help... can't seem to find anyone else with this issue either?
Any help would be appreciated.

samsnull said:
Currently ripping my hair out over this. I have a very annoying problem with this S7 Edge which at random intervals, usually once a week or so, becomes completely unresponsive while the screen is off. Meaning that you can't turn on the screen or do anything other than a force reboot. Calling the phone works as in the caller hears the dial tone, but the Edge doesn't react at all. Have tried a complete factory reset, didn't help... can't seem to find anyone else with this issue either?
Any help would be appreciated.
Click to expand...
Click to collapse
Are you using the engineering kernel. Or is device stock? Need a little more info.

TheMadScientist said:
Are you using the engineering kernel. Or is device stock? Need a little more info.
Click to expand...
Click to collapse
All stock, Nougat (though I've had this problem on Marshmallow too). Not sure if I should try a custom rom/kernel, as I should be able to return it assuming I can somehow have the RMA people reproduce the issue. I'm starting to feel like this is a hardware problem though, the phone won't even charge when it happens...

Not really related to S7 Edge, but I saw your post and thought it would be worth to mention I had this happen to me long ago, cannot be sure what device and OS even. But I can say it was not directly related to S7 (edge) or Nougat (because it was lonf ago). Maybe S6, or even Sony Xperia z3 Compact.

I may have found the cause. It just happened and I rebooted and ran an adb bugreport a few minutes after I found it "dead", and saw some interesting logcat entries. A small selection of them, in order from last night to a few minutes before I rebooted:
Code:
11-01 04:05:39.697 4743 4936 D B!tteryServiCe: [email protected] : badteryPropertiesChanged
10-08 05:01:04.817 4743 5112 I Libsuspend: [email protected]%nd_thread_func: writ% mem do /sy3/power/state
07-31 18:47:26.428 4743 4856 I libsuspend: @3uspend_tHread_func8 srite 64306
10-26 06:58:11.854 4743 5112 I libsuspend: [email protected]$[thread\37func: wait
JNI: [email protected]`dActi/ns(172), !ctioj=1, wmActions=1
07-17 20:28:52.634 4743 4856 I libsuspdnd: [email protected]_t(read_fun#: write mem to /sys/power-st
04-30 11:32:10.817 4743 5112 I libquspend: [email protected]_thread_func: rdad wakeup_count
11-01 08:19:10.391 647 5323 D Hnp5TMala&er-JN : [email protected]\b11&), ac$hol=1, WmActions=0
11-01 08:19:10.752 4743 5109 D D)splayPo7erStatd: [email protected] [0] ColorFade entry
11-01 11:15:19.974 4743 4987 D UsbMonitorService: [email protected]`State \20 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Looks like a bit flipping CPU/RAM issue to me, and the errors seem to get more frequent as time goes on. I didn't find even any in the post-reboot logcat. There's similar stuff in the pre-reboot kmsg. It also seems that when it became unresponsive, it stopped outputting libsuspend logs (the last thing it did was "read wakeup_count"), except for a "autosuspend_wakeup_count_disable" and a "autosuspend_wakeup_count_disable done" when I tried to turn the screen on (a "Screen__On" message was also written just before those), and instead started outputting more io_stats logs than usual.
I'll try to find a proper way to present this to Samsung so that I can get a replacement...

Podcast Addict Issues

I am reposting this because the issue remains and when I first posted in July I received a single response from a user that was also experiencing this.
I can't seem to find an answer anywhere. Basically when listening to a podcast with the Podcast Addict player at ~1.9x or faster the audio stutters and produces a static sound distorting the audio. Waking the screen immediately stops the issue. The issue gets worse if you increase the speed or enable the "skip silence" feature.
I made sure to disable any battery saving options for the app and enabled any workaround options within the app. I even contacted the developer who pretty much just said that the phone is governing the processor too low with the screen off. I have tested other podcast apps and they seem to function fine even at faster playback speeds. For some reason, this only affects Podcast Addict.
Is anyone else experiencing this? Anybody have a suggestion for a fix? I am completely stock OOS version 4.5.14. I have the 8/128GB model if it makes a difference.
It seems to have issues even if the screen is on and the app is not in the foreground. Within ~5 seconds of being put into the background, it begins to stutter.
I have been working with OnePlus' own "bug hunter team" to fix this but I have not heard from them in over a month since I reported it to them. They asked me clear cache and reproduce the effect on my device and send them logs, which I did but I haven't heard anything.
Can anyone test this and tell me if they don't have an issue with screen off?

I also couldn't get rid of the static sound in Podcast Addict when playing back at fast speeds (for me, around 1.7x or faster). This was on a Galaxy S8+. I've been listening to a podcast audiobook Wildbow's "Worm" (which weighs in in at 6,680 pages) and the static sound was killing my ears. Gave up on Podcast Addict today, and switched to Pocket Casts and not having any static problems now when listening at faster speeds.

I think I found the problem with Podcast Addict stuttering... it's the logging.
I've gotten into the habit of pinning my CPU frequency to 299 MHz maximum to save battery, and PA would stutter, so I dug into ADB to figure out what was going on. After getting rid of the hidden adware that the phone's manufacturer kept running in the background, CPU usage dropped enough that I could run PA without much stutter, but if I opened the notifications or ran any other app, it'd start stuttering again. So I dug further.
And it seemed that as I increased maximum CPU speed from 299 MHz to 1.3 GHz, CPU utilization would increase, too, if Podcast Addict was running. That was strange behavior, so I knew something was going on.
Apparently the system is somehow hooking into PA and logging everything PA is logging internally. When I run:
adb logcat -D -v long > c:\test\logcat.log
... the logcat.log file swells up to 80 - 110 MB in a mere minute. Without PA running, it's generally around 113 KB / minute.
So I started killing logging processes.
I killed logcat, and CPU usage dropped dramatically, but logd started hogging the CPU.
So I killed logd. It restarted, but no longer hogged the CPU.
So CPU utilization dropped from ~83% for PA, utilizing 4 to 5 cores, to ~60% for PA, utilizing 3 cores. Even with the CPU pinned to a maximum 299 MHz, playback was smooth.
As for logcat, after killing it, if you run it from your computer:
adb logcat -D -v long > c:\test\logcat.log
it'll begin log-spamming again (its the AudioTrack thread which is spamming the log) and the phone's CPU usage spikes again, but now, after having killed logcat once, when I stop logcat logging via ADB, logcat stops spamming the log and the phone's CPU usage returns to using 3 cores.
Get the CPU usage info:
adb shell dumpsys cpuinfo
inside that info, you'll see the PID of the applications. Look for logcat and logd. There might be more than 1 logcat, kill them all.
Let's say logcat is running two instances, with PID 239 and PID 760, for example (it'll be different each time you boot the phone), and logd with PID 13020.
Then issue the following commands from a command prompt on your computer:
adb shell
su
kill 239
kill 760
kill 13020
exit
exit
On my computer, if I type the commands too fast, ADB can't keep up, and ADB will crash, so give it a few seconds in between each command.
The above-described log-spamming behavior reoccurs upon reboot, so you'd have to do this after each boot.
Now I can listen to podcasts (I usually listen at 2x, sometimes as high as 3x for podcasters who talk slowly) without stutter, with the octa-core CPU pinned to 299 MHz maximum.