Frequent OutOfMemory while playing in background

[mabakay]

Checklist

• I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• 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

[opusforlife2]

How much RAM do you have? How much of it is generally free? You can check using Running Services in Developer Options.

[mabakay]

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 :-?).

[TobiGr]

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:

1. Please download, extract and install this apk: app-debug.zip
2. Open the newly installed "NewPipe Debug" app
3. Go to settings > debugging and enable these two options: LeakCanary and Report out of life-cycle errors
4. Open the normal NewPipe version, export your app database and import it into the debug version as explained in our FAQ
5. Please keep using the Debug version for a few days and report memory issues found by LeakCanary to us

[mabakay]

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
==================================== 

[mabakay]

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
==================================== 

[feuerswut]

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.

[vitidev]

Recommended at least 4-6GiB RAM.

ReVanced (which is just as memory-intensive) works without any issues on the same device, while NewPipe is guaranteed to crash. Interestingly, the sound might keep playing, and you can restart the video layer by tapping on the video.

In my case, it’s enough to just open a video (not even in the background, but simply open https://www.youtube.com/watch?v=eCtA55pc_K8). If it’s 1080p, it crashes almost immediately. If it’s 720p, the video layer will periodically crash every minute, while the audio keeps playing. Tapping restarts the video layer. By tapping every 30-60 seconds, you can watch the entire video. Of course, this doesn’t happen with every video, but this particular one breaks NewPipe right away.

Exception

• User Action: play stream
• Request: Player error[type=ERROR_CODE_IO_UNSPECIFIED] occurred while playing https://www.youtube.com/watch?v=eCtA55pc_K8
• Content Country: RU
• Content Language: ru-RU
• App Language: ru_RU
• Service: YouTube
• Timestamp: 2025-03-10T11:25:14.383+03:00
• Package: org.schabi.newpipe
• Service: YouTube
• Version: 0.27.6
• 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 59952 free bytes and 58KB 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 59952 free bytes and 58KB 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

---