Frequent OutOfMemory while playing in background
Checklist
- [X] I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
- [X] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
- [X] I have read the FAQ and my problem isn't listed.
- [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
- [X] This issue contains only one bug.
- [X] I have read and understood the contribution guidelines.
Affected version
0.26.0
Steps to reproduce the bug
Start playing long YT music video and send application to background. After while sound hang and android device become sloooow until NewPipe forced closed.
Expected behavior
No response
Actual behavior
No response
Screenshots/Screen recordings
No response
Logs
Exception
- User Action: play stream
- Request: Player error[type=ERROR_CODE_IO_UNSPECIFIED] occurred while playing https://www.youtube.com/watch?v=GkqhHEAy1zw
- Content Country: PL
- Content Language: pl-PL
- App Language: pl_PL
- Service: YouTube
- Version: 0.26.0
- OS: Linux Android 6.0 - 23
Crash log
com.google.android.exoplayer2.ExoPlaybackException: Source error
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:644)
at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:620)
at android.os.Handler.dispatchMessage(Handler.java:107)
at android.os.Looper.loop(Looper.java:207)
at android.os.HandlerThread.run(HandlerThread.java:61)
Caused by: com.google.android.exoplayer2.upstream.Loader$UnexpectedLoaderException: Unexpected OutOfMemoryError: Failed to allocate a 65548 byte allocation with 48304 free bytes and 47KB until OOM
at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:441)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
at java.lang.Thread.run(Thread.java:818)
Caused by: java.lang.OutOfMemoryError: Failed to allocate a 65548 byte allocation with 48304 free bytes and 47KB until OOM
at com.google.android.exoplayer2.upstream.DefaultAllocator.allocate(DefaultAllocator.java:102)
at com.google.android.exoplayer2.source.SampleDataQueue.preAppend(SampleDataQueue.java:233)
at com.google.android.exoplayer2.source.SampleDataQueue.sampleData(SampleDataQueue.java:176)
at com.google.android.exoplayer2.source.SampleQueue.sampleData(SampleQueue.java:590)
at com.google.android.exoplayer2.extractor.TrackOutput$-CC.$default$sampleData(TrackOutput.java:157)
at com.google.android.exoplayer2.source.SampleQueue.sampleData(SampleQueue.java:0)
at com.google.android.exoplayer2.source.chunk.BundledChunkExtractor$BindingTrackOutput.sampleData(BundledChunkExtractor.java:227)
at com.google.android.exoplayer2.extractor.TrackOutput$-CC.$default$sampleData(TrackOutput.java:157)
at com.google.android.exoplayer2.source.chunk.BundledChunkExtractor$BindingTrackOutput.sampleData(BundledChunkExtractor.java:0)
at com.google.android.exoplayer2.extractor.mp4.FragmentedMp4Extractor.readSample(FragmentedMp4Extractor.java:1455)
at com.google.android.exoplayer2.extractor.mp4.FragmentedMp4Extractor.read(FragmentedMp4Extractor.java:344)
at com.google.android.exoplayer2.source.chunk.BundledChunkExtractor.read(BundledChunkExtractor.java:147)
at com.google.android.exoplayer2.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:127)
at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:412)
... 3 more
Affected Android/Custom ROM version
Android 6
Affected device model
Lenovo TAB 10M
Additional information
No response
How much RAM do you have? How much of it is generally free? You can check using Running Services in Developer Options.
Tablet has 2GB RAM, usually 1.4GB in use, NewPipe highest usage 286MB (usually ~30-40MB).
I installed 0.26.1 yesterday and it seems to be a lot better. I don't know if it matters, but previous version was debug version (I believe :-?).
There was only a little fix for media.ccc.de in the 0.26.1 update and no other changes. 30-40MB memory usage sounds pretty normal to me. The "normal" NewPipe version is never a debug version so you shouldn't get higher memory usage due to debugging. But speaking of debug versions, we might be able to check whether there are memory leaks causing the out of memory exceptions:
- Please download, extract and install this apk: app-debug.zip
- Open the newly installed "NewPipe Debug" app
- Go to
settings > debuggingand enable these two options:LeakCanaryandReport out of life-cycle errors - Open the normal NewPipe version, export your app database and import it into the debug version as explained in our FAQ
- Please keep using the Debug version for a few days and report memory issues found by LeakCanary to us
First day:
====================================
HEAP ANALYSIS RESULT
====================================
3 APPLICATION LEAKS
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
8291 bytes retained by leaking objects
Signature: d11ff09a15f90e0c4d9c0d037783afc15611da16
┬───
│ GC Root: System class
│
├─ leakcanary.internal.InternalLeakCanary class
│ Leaking: NO (MainActivity↓ is not leaking and a class is never leaking)
│ ↓ static InternalLeakCanary.resumedActivity
├─ org.schabi.newpipe.MainActivity instance
│ Leaking: NO (DefaultKioskFragment↓ is not leaking and Activity#mDestroyed
│ is false)
│ mApplication instance of org.schabi.newpipe.DebugApp
│ mBase instance of androidx.appcompat.view.ContextThemeWrapper
│ ↓ ComponentActivity.mOnConfigurationChangedListeners
├─ java.util.concurrent.CopyOnWriteArrayList instance
│ Leaking: NO (DefaultKioskFragment↓ is not leaking)
│ ↓ CopyOnWriteArrayList[3]
├─ androidx.fragment.app.FragmentManager$$ExternalSyntheticLambda0 instance
│ Leaking: NO (DefaultKioskFragment↓ is not leaking)
│ ↓ FragmentManager$$ExternalSyntheticLambda0.f$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│ Leaking: NO (DefaultKioskFragment↓ is not leaking)
│ ↓ FragmentManager.mParent
├─ org.schabi.newpipe.fragments.list.kiosk.DefaultKioskFragment instance
│ Leaking: NO (Fragment#mFragmentManager is not null)
│ activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ BaseListFragment.itemsList
│ ~~~~~~~~~
├─ org.schabi.newpipe.views.NewPipeRecyclerView instance
│ Leaking: UNKNOWN
│ Retaining 914,7 kB in 16749 objects
│ View not part of a window view hierarchy
│ View.mAttachInfo is null (view detached)
│ View.mID = R.id.items_list
│ View.mWindowAttachCount = 1
│ mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ View.mParent
│ ~~~~~~~
╰→ android.widget.RelativeLayout instance
Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
fragments.list.kiosk.DefaultKioskFragment received
Fragment#onDestroyView() callback (references to its views should be
cleared to prevent leaks))
Retaining 8,3 kB in 153 objects
key = 416a275e-e8cb-497e-af67-b28d12e11b87
watchDurationMillis = 20414
retainedDurationMillis = 15407
View not part of a window view hierarchy
View.mAttachInfo is null (view detached)
View.mWindowAttachCount = 1
mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
false
40891 bytes retained by leaking objects
Signature: fd701ea3f16f206e3cd063cce0849048a9fbf8a7
┬───
│ GC Root: System class
│
├─ leakcanary.internal.InternalLeakCanary class
│ Leaking: NO (MainActivity↓ is not leaking and a class is never leaking)
│ ↓ static InternalLeakCanary.resumedActivity
├─ org.schabi.newpipe.MainActivity instance
│ Leaking: NO (FeedFragment↓ is not leaking and Activity#mDestroyed is false)
│ mApplication instance of org.schabi.newpipe.DebugApp
│ mBase instance of androidx.appcompat.view.ContextThemeWrapper
│ ↓ ComponentActivity.mOnConfigurationChangedListeners
├─ java.util.concurrent.CopyOnWriteArrayList instance
│ Leaking: NO (FeedFragment↓ is not leaking)
│ ↓ CopyOnWriteArrayList[4]
├─ androidx.fragment.app.FragmentManager$$ExternalSyntheticLambda0 instance
│ Leaking: NO (FeedFragment↓ is not leaking)
│ ↓ FragmentManager$$ExternalSyntheticLambda0.f$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│ Leaking: NO (FeedFragment↓ is not leaking)
│ ↓ FragmentManager.mParent
├─ org.schabi.newpipe.local.feed.FeedFragment instance
│ Leaking: NO (Fragment#mFragmentManager is not null)
│ activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ BaseStateFragment.errorPanelHelper
│ ~~~~~~~~~~~~~~~~
├─ org.schabi.newpipe.error.ErrorPanelHelper instance
│ Leaking: UNKNOWN
│ Retaining 24,0 kB in 654 objects
│ context instance of org.schabi.newpipe.MainActivity with mDestroyed = false
│ ↓ ErrorPanelHelper.errorPanelRoot
│ ~~~~~~~~~~~~~~
├─ android.widget.LinearLayout instance
│ Leaking: UNKNOWN
│ Retaining 1,3 kB in 17 objects
│ View not part of a window view hierarchy
│ View.mAttachInfo is null (view detached)
│ View.mID = R.id.error_panel
│ View.mWindowAttachCount = 1
│ mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ View.mParent
│ ~~~~~~~
╰→ android.widget.RelativeLayout instance
Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
local.feed.FeedFragment received Fragment#onDestroyView() callback
(references to its views should be cleared to prevent leaks))
Retaining 40,9 kB in 837 objects
key = 3883112b-9937-4170-a26b-bfb56ec675b7
watchDurationMillis = 20412
retainedDurationMillis = 15407
View not part of a window view hierarchy
View.mAttachInfo is null (view detached)
View.mWindowAttachCount = 1
mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
false
2283 bytes retained by leaking objects
Signature: 671e857767fe3ac70c7b82cad2a093491a8adb06
┬───
│ GC Root: System class
│
├─ leakcanary.internal.InternalLeakCanary class
│ Leaking: NO (MainActivity↓ is not leaking and a class is never leaking)
│ ↓ static InternalLeakCanary.resumedActivity
├─ org.schabi.newpipe.MainActivity instance
│ Leaking: NO (MainFragment↓ is not leaking and Activity#mDestroyed is false)
│ mApplication instance of org.schabi.newpipe.DebugApp
│ mBase instance of androidx.appcompat.view.ContextThemeWrapper
│ ↓ ComponentActivity.mOnConfigurationChangedListeners
├─ java.util.concurrent.CopyOnWriteArrayList instance
│ Leaking: NO (MainFragment↓ is not leaking)
│ ↓ CopyOnWriteArrayList[2]
├─ androidx.fragment.app.FragmentManager$$ExternalSyntheticLambda0 instance
│ Leaking: NO (MainFragment↓ is not leaking)
│ ↓ FragmentManager$$ExternalSyntheticLambda0.f$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│ Leaking: NO (MainFragment↓ is not leaking)
│ ↓ FragmentManager.mParent
├─ org.schabi.newpipe.fragments.MainFragment instance
│ Leaking: NO (Fragment#mFragmentManager is not null)
│ activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ MainFragment.pagerAdapter
│ ~~~~~~~~~~~~
├─ org.schabi.newpipe.fragments.MainFragment$SelectedTabsPagerAdapter instance
│ Leaking: UNKNOWN
│ Retaining 57,4 kB in 834 objects
│ context instance of org.schabi.newpipe.MainActivity with mDestroyed = false
│ ↓ PagerAdapter.mViewPagerObserver
│ ~~~~~~~~~~~~~~~~~~
├─ androidx.viewpager.widget.ViewPager$PagerObserver instance
│ Leaking: UNKNOWN
│ Retaining 12 B in 1 objects
│ ↓ ViewPager$PagerObserver.this$0
│ ~~~~~~
├─ androidx.viewpager.widget.ViewPager instance
│ Leaking: UNKNOWN
│ Retaining 2,6 kB in 49 objects
│ View not part of a window view hierarchy
│ View.mAttachInfo is null (view detached)
│ View.mID = R.id.pager
│ View.mWindowAttachCount = 1
│ mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ View.mParent
│ ~~~~~~~
╰→ android.widget.RelativeLayout instance
Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
fragments.MainFragment received Fragment#onDestroyView() callback
(references to its views should be cleared to prevent leaks))
Retaining 2,3 kB in 58 objects
key = 8d1e3cfc-c122-46a8-b2d1-d56c8c763c6a
watchDurationMillis = 20411
retainedDurationMillis = 15406
View not part of a window view hierarchy
View.mAttachInfo is null (view detached)
View.mWindowAttachCount = 1
mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
false
====================================
0 LIBRARY LEAKS
A Library Leak is a leak caused by a known bug in 3rd party code that you do
not have control over.
See https://square.github.
io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS
An unreachable object is still in memory but LeakCanary could not find a strong
reference path
from GC roots.
====================================
METADATA
Please include this in bug reports and Stack Overflow questions.
Build.VERSION.SDK_INT: 23
Build.MANUFACTURER: LENOVO
LeakCanary version: 2.12
App process name: org.schabi.newpipe.debug
Class count: 10297
Instance count: 269439
Primitive array count: 153405
Object array count: 36642
Thread count: 64
Heap total bytes: 46721367
Bitmap count: 455
Bitmap total bytes: 0
Large bitmap count: 0
Large bitmap total bytes: 0
Db 1: open /data/user/0/org.schabi.newpipe.debug/no_backup/androidx.work.workdb
Db 2: open /data/user/0/org.schabi.newpipe.debug/databases/newpipe.db
Db 3: open /data/user/0/org.schabi.newpipe.debug/databases/exoplayer_internal.db
Stats: LruCache[maxSize=3000,hits=70654,misses=196361,hitRate=26%]
RandomAccess[bytes=12375625,reads=196361,travel=176205625749,range=33342607,size
=59516027]
Analysis duration: 101749 ms
Heap dump file path: /data/user/0/org.schabi.newpipe.
debug/cache/leakcanary/2023-12-31_18-31-19_222.hprof
Heap dump timestamp: 1704043999516
Heap dump duration: Unknown
====================================
Second day:
====================================
HEAP ANALYSIS RESULT
====================================
1 APPLICATION LEAKS
References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.
2358630 bytes retained by leaking objects
Displaying only 1 leak trace out of 2 with the same signature
Signature: 42620d49fd0850d585828ac29275686e1e55bf3d
┬───
│ GC Root: System class
│
├─ leakcanary.internal.InternalLeakCanary class
│ Leaking: NO (MainActivity↓ is not leaking and a class is never leaking)
│ ↓ static InternalLeakCanary.resumedActivity
├─ org.schabi.newpipe.MainActivity instance
│ Leaking: NO (MainFragment↓ is not leaking and Activity#mDestroyed is false)
│ mApplication instance of org.schabi.newpipe.DebugApp
│ mBase instance of androidx.appcompat.view.ContextThemeWrapper
│ ↓ ComponentActivity.mOnConfigurationChangedListeners
├─ java.util.concurrent.CopyOnWriteArrayList instance
│ Leaking: NO (MainFragment↓ is not leaking)
│ ↓ CopyOnWriteArrayList[2]
├─ androidx.fragment.app.FragmentManager$$ExternalSyntheticLambda0 instance
│ Leaking: NO (MainFragment↓ is not leaking)
│ ↓ FragmentManager$$ExternalSyntheticLambda0.f$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│ Leaking: NO (MainFragment↓ is not leaking)
│ ↓ FragmentManager.mParent
├─ org.schabi.newpipe.fragments.MainFragment instance
│ Leaking: NO (Fragment#mFragmentManager is not null)
│ activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ MainFragment.pagerAdapter
│ ~~~~~~~~~~~~
├─ org.schabi.newpipe.fragments.MainFragment$SelectedTabsPagerAdapter instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 39278 objects
│ context instance of org.schabi.newpipe.MainActivity with mDestroyed = false
│ ↓ PagerAdapter.mObservable
│ ~~~~~~~~~~~
├─ android.database.DataSetObservable instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 39135 objects
│ ↓ Observable.mObservers
│ ~~~~~~~~~~
├─ java.util.ArrayList instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 39134 objects
│ ↓ ArrayList[0]
│ ~~~
├─ com.google.android.material.tabs.TabLayout$PagerAdapterObserver instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 39132 objects
│ ↓ TabLayout$PagerAdapterObserver.this$0
│ ~~~~~~
├─ org.schabi.newpipe.views.ScrollableTabLayout instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 39131 objects
│ View not part of a window view hierarchy
│ View.mAttachInfo is null (view detached)
│ View.mID = R.id.main_tab_layout
│ View.mWindowAttachCount = 1
│ mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ TabLayout.viewPager
│ ~~~~~~~~~
├─ androidx.viewpager.widget.ViewPager instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 38359 objects
│ View not part of a window view hierarchy
│ View.mAttachInfo is null (view detached)
│ View.mID = R.id.pager
│ View.mWindowAttachCount = 1
│ mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│ false
│ ↓ ViewPager.mItems
│ ~~~~~~
├─ java.util.ArrayList instance
│ Leaking: UNKNOWN
│ Retaining 2,4 MB in 38313 objects
│ ↓ ArrayList[0]
│ ~~~
├─ androidx.viewpager.widget.ViewPager$ItemInfo instance
│ Leaking: UNKNOWN
│ Retaining 2,3 MB in 36550 objects
│ ↓ ViewPager$ItemInfo.object
│ ~~~~~~
╰→ org.schabi.newpipe.fragments.list.kiosk.DefaultKioskFragment instance
Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
fragments.list.kiosk.DefaultKioskFragment received Fragment#onDestroy()
callback and Fragment#mFragmentManager is null)
Retaining 2,3 MB in 36549 objects
key = a684d83a-20ed-494d-a94d-29ea6fd2aa04
watchDurationMillis = 8262
retainedDurationMillis = 3236
====================================
0 LIBRARY LEAKS
A Library Leak is a leak caused by a known bug in 3rd party code that you do
not have control over.
See https://square.github.
io/leakcanary/fundamentals-how-leakcanary-works/#4-categorizing-leaks
====================================
0 UNREACHABLE OBJECTS
An unreachable object is still in memory but LeakCanary could not find a strong
reference path
from GC roots.
====================================
METADATA
Please include this in bug reports and Stack Overflow questions.
Build.VERSION.SDK_INT: 23
Build.MANUFACTURER: LENOVO
LeakCanary version: 2.12
App process name: org.schabi.newpipe.debug
Class count: 11419
Instance count: 376734
Primitive array count: 208110
Object array count: 55532
Thread count: 73
Heap total bytes: 110755146
Bitmap count: 548
Bitmap total bytes: 0
Large bitmap count: 0
Large bitmap total bytes: 0
Db 1: open /data/user/0/org.schabi.newpipe.debug/no_backup/androidx.work.workdb
Db 2: open /data/user/0/org.schabi.newpipe.debug/databases/newpipe.db
Db 3: open /data/user/0/org.schabi.newpipe.debug/databases/exoplayer_internal.db
Stats: LruCache[maxSize=3000,hits=80586,misses=278852,hitRate=22%]
RandomAccess[bytes=16510254,reads=278852,travel=423762059187,range=43226463,size
=126940774]
Analysis duration: 128655 ms
Heap dump file path: /data/user/0/org.schabi.newpipe.
debug/cache/leakcanary/2023-12-31_22-08-01_718.hprof
Heap dump timestamp: 1704064644819
Heap dump duration: Unknown
====================================
It's the memory overflowing again. It's not getting fixed until the rewrite. Clear cache, search queries, history? Or all app data (make backups). Recommended at least 4-6GiB RAM.