java.lang.OutOfMemoryError: Failed to allocate a 16 byte allocation with 1033328 free bytes and 1009KB until OOM, target footprint 268435456, growth limit 268435456; giving up on allocation because <1% of heap free after GC.
at android.os.ThreadLocalWorkSource.setUid(ThreadLocalWorkSource.java:68)
at android.os.Looper.loopOnce(Looper.java:199)
at android.os.Looper.loop(Looper.java:288)
at android.os.HandlerThread.run(HandlerThread.java:67)
I’m not an expert on such things, but the trace sure seems to indicate that the phone is low on some kind of memory resource. Have you tried restarting the phone?
Thanks for your reply and idea! Yes, actually I exactly tried that before submitting the bug report. But shortly after the phone was restarted, it happened again. I was surfing the internet besides listening, using the Firefox mobile browser, but I would assume that’s not too resource consuming. And as said I didn’t change my phone nor behaviour since this happens.
Do you use synchronization? Are you subscribed to a very large number of podcasts? Do you have a huge number of episodes in the app (you can view the number by going to the “all episodes” screen and starting multi-select)
Thanks for your reply! Synchronization: no. What is a lot of subscriptions and episodes? Anyway, I don’t see any number except in the playlist. There a number of 688 episodes with a playtime of around 200 hours have accumulated over the time. Is this a lot and does this have an influence on performance?
Anyway, I didn’t want to bother with an individual problem. But as this problem didn’t exist before (where I did also have quite some subscriptions), I thought it might be a general problem / bug.
Good morning, I had tried to do what you asked me for, but this option seems to not be available in the German app version. Shouldn’t the app work quickly independently of the number of subscriptions, though? The inbox also loads slowly sometimes, maybe the app tries to load too much at once? Is sequential loading possible somehow to speed up loading processes?
I’ve too have noticed the same, starting around the same time. Sometimes, the player just stops for a good minute. Sometimes instead of stopping, it just crashes. FYI, I have moto G7 2019, Andoird 10 with plenty of available storage space. But if I have 1000 episodes, downloaded and in queue, is that too much and a contributing factor? Should I start deleting? Furthermore, once the app starts regularly crashing, short of deleting the app entirely and finding another pdocast app to use that works reliably, could there be some kind checklist of steps to take to work back towards having a stable player?
I’ve found a “solution” (workaround) for myself meanwhile: I switched off automatic, regular downloads, as this process seems to have taken up too much memory. It lead to stopping the app and once the app was started again, the download process also started again - from the beginning.
So now I start the download process manually, and mostly it manages to finish successfully. This is also less stressful for myself, as the inbox is filling up with new episodes only when I’m prepared for it.
Hope this helps also in your case!
A proper solution, though, would be to design the download process in a way that it doesn’t lead to app crashes.
Btw, I like the new download process notification that was introduced some weeks ago! This way we can see how the download process is progressing and if it’s active. Congrats to the developers for this idea.
No, my notifications were always turned on and I was using notifications for certain new episodes. So either the update process notification wasn’t working on my phone or I hadn’t recognized it.
Regarding the manual update process (as I just used it again before):
The update process in my case is currently handling 368 downloads, which I guess is not that much (compared to the 1000 downloads the other user mentioned above).
Still, when I’m not actively using AntennaPod while the download is running (and even if I’m using nothing else on the phone meanwhile), it often doesn’t finish (either because the app crashes or because Android stopps it - I’ve given unlimited battery use permission to AntennaPod, though).
The process mostly (and like before) only manages to finish when I’m listening some podcast while the process is active (and if the app doesn’t crash).
So I still believe that the process should be optimized somehow to make sure it finishes. At least it shouldn’t start all from the beginning again, shortly after it has been stopped by force and just restarted again.
As said in the beginning (and as can be seen in my initially posted bug report), my phone is no luxury, but I have no speed nor performance nor storage issues. Actually I perceive the (not so old) phone as quite modern and fast, so it should be capable to handle a download process (which doesn’t even download huge amount of data, as I’m not downloading podcast files right away, but only episodes info).
You probably just enabled notifications for AntennaPod