Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newpipe is incredible slow under Chrome OS (Chromebook) #7459

Open
Gill-Grmn opened this issue Nov 28, 2021 · 12 comments
Open

Newpipe is incredible slow under Chrome OS (Chromebook) #7459

Gill-Grmn opened this issue Nov 28, 2021 · 12 comments
Labels
bug Issue is related to a bug device/software specific Issues that only happen on some devices or with some specific hardware/software template missing The bug/feature template is missing (e.g. the used app does not support issue templates)

Comments

@Gill-Grmn
Copy link

Gill-Grmn commented Nov 28, 2021

When using Newpipe at my Android capable Chromebook (running Chrome OS 96 / 97, it is a ligning fast Acer Spin 713-2W with i5-CPU) it needs at least 20 seconds to show any content and also to start video playback.

This problem exists since about 3 oder 2 month and neithter updating Chromebook (started with Chrome OS 95) nor updating Newpipe had changed this issue.

I do not have this issue with all my othe Android capable devices (Newpipe 0.21.13 runs smooth at alls my other Android devices, they all using exactly the same internet connection as my Chromebook. All other Android Apps and even runnijng Youtube directly is running fine at my Chromebook

@Gill-Grmn Gill-Grmn changed the title Newpipe is incedible slow under Chrome OS Chromebook Newpipe is incredible slow under Chrome OS (Chromebook) Nov 28, 2021
@TobiGr TobiGr transferred this issue from TeamNewPipe/website Nov 28, 2021
@TobiGr TobiGr added the device/software specific Issues that only happen on some devices or with some specific hardware/software label Nov 28, 2021
@litetex
Copy link
Member

litetex commented Nov 29, 2021

it needs at least 20 seconds to show any content and also to start video playback

Looks like a GPU or network problem.

@Gill-Grmn
Copy link
Author

Looks like a GPU or network problem.

My i5-Chromebook runs lighting fast and smooth as OTHER instlalled Android apps do. Same with network connection (260 Mbps Internet download/ 110 Mbps upload). Video playback via directly Youtube.com runs also smooth as butter. Newpipe is the only application that runs with a "handbrake": With (only) Newpipe getting search results and video thumbnails etc. is slow with 20 - 40 seconds video/preview/search result ... loading time

@litetex
Copy link
Member

litetex commented Nov 30, 2021

Ok some things that might help:

  1. You are running NewPipe on chromebook. I don't know if that is fully supported, as NewPipe was built for (stock) Android in the first place
  2. I assume you already did - but did you reinstall the app (you might export your settings first...)? Did the problems persist afterwards?
  3. Are there any network or otherwise limiting settings active? Maybe only for Android apps on the chromebook?
  4. With the above information I can't help any further. We need something to narrow down the problem. Usually logs (of a debug build - latest one available here) help. So it would be great if you could share those.

@Gill-Grmn
Copy link
Author

  1. I assume you already did - but did you reinstall the app (you might export your settings first...)? Did the problems persist afterwards?

The problems persist after uninstalling and reinstalling Newpipe. Reinstalling does not help

  1. Are there any network or otherwise limiting settings active? Maybe only for Android apps on the chromebook?

There are no special Android network settings at Chromebook and other Android Apps are (net-)working fine and smooth.

Even Newpipe itself has fast download speed when I use it Video/Audio-file-download functionality: downloading a Youtube-Video via Newpipe as MPEG-4 720p with ~50MB size is done within about 5 seconds).

BUT every other Newipipe action is slow when it hast to show a listing (i.e. listing of a video search result OR a list of all videos of single YT-channel) and it also needs more than 20 seconds every time when it has to start simple YT-video-playback and even for showing YT-Video-informations like channel descriptions and user comments etc.

  1. With the above information I can't help any further. We need something to narrow down the problem. Usually logs (of a debug build - latest one available here) help. So it would be great if you could share those.

I would really like to install a Newpipe-Debug-APK and then send debug informations but I could not find any debug-APK at the above URL nor any where else.

@litetex
Copy link
Member

litetex commented Dec 1, 2021

I would really like to install a Newpipe-Debug-APK and then send debug informations but I could not find any debug-APK at the above URL nor any where else.

From our PR template:

APK testing

The APK can be found by going to the "Checks" tab below the title. On the left pane, click on "CI", scroll down to "artifacts" and click "app" to download the zip file which contains the debug APK of this PR.

grafik

Note: You have to be logged in to see the artifact.

@Gill-Grmn
Copy link
Author

Gill-Grmn commented Dec 3, 2021

Thanks!

I've installed the debug-APK and it runs. How can I find a debug log? Can't find a logfile setting in the debug-APK-settings (see screenshot)

@Gill-Grmn
Copy link
Author

Gill-Grmn commented Dec 3, 2021

I've found this:

Click to see details
====================================
HEAP ANALYSIS RESULT
====================================
5 APPLICATION LEAKS

References underlined with "~~~" are likely causes.
Learn more at https://squ.re/leaks.

2683 bytes retained by leaking objects
Signature: 4bb989b87242c1f13d563c5196326e4df01ad387
┬───
│ GC Root: Global variable in native code
│
├─ android.database.ContentObserver$Transport instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    ↓ ContentObserver$Transport.mContentObserver
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment$1 instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    Anonymous subclass of android.database.ContentObserver
│    ↓ VideoDetailFragment$1.this$0
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment instance
│    Leaking: NO (MainFragment↓ is not leaking and Fragment#mFragmentManager is
│    not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ VideoDetailFragment.mFragmentManager
├─ androidx.fragment.app.FragmentManagerImpl instance
│    Leaking: NO (MainFragment↓ is not leaking)
│    ↓ FragmentManagerImpl.mFragmentStore
├─ androidx.fragment.app.FragmentStore instance
│    Leaking: NO (MainFragment↓ is not leaking)
│    ↓ FragmentStore.mActive
├─ java.util.HashMap instance
│    Leaking: NO (MainFragment↓ is not leaking)
│    ↓ HashMap.table
├─ java.util.HashMap$Node[] array
│    Leaking: NO (MainFragment↓ is not leaking)
│    ↓ HashMap$Node[].[0]
├─ java.util.HashMap$Node instance
│    Leaking: NO (MainFragment↓ is not leaking)
│    ↓ HashMap$Node.value
├─ androidx.fragment.app.FragmentStateManager instance
│    Leaking: NO (MainFragment↓ is not leaking)
│    ↓ FragmentStateManager.mFragment
├─ org.schabi.newpipe.fragments.MainFragment instance
│    Leaking: NO (Fragment#mFragmentManager is not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ MainFragment.binding
│                   ~~~~~~~
├─ org.schabi.newpipe.databinding.FragmentMainBinding instance
│    Leaking: UNKNOWN
│    Retaining 65737 bytes in 643 objects
│    ↓ FragmentMainBinding.rootView
│                          ~~~~~~~~
╰→ 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 2683 bytes in 70 objects
​     key = 775ea19b-0e46-4235-86cc-6131e0a778cb
​     watchDurationMillis = 35769
​     retainedDurationMillis = 25769
​     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

11112 bytes retained by leaking objects
Signature: 184f90a8501a27d42032f6d5f3164995ee05fe0
┬───
│ GC Root: Global variable in native code
│
├─ android.database.ContentObserver$Transport instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    ↓ ContentObserver$Transport.mContentObserver
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment$1 instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    Anonymous subclass of android.database.ContentObserver
│    ↓ VideoDetailFragment$1.this$0
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment instance
│    Leaking: NO (SearchFragment↓ is not leaking and Fragment#mFragmentManager
│    is not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ VideoDetailFragment.mFragmentManager
├─ androidx.fragment.app.FragmentManagerImpl instance
│    Leaking: NO (SearchFragment↓ is not leaking)
│    ↓ FragmentManagerImpl.mFragmentStore
├─ androidx.fragment.app.FragmentStore instance
│    Leaking: NO (SearchFragment↓ is not leaking)
│    ↓ FragmentStore.mActive
├─ java.util.HashMap instance
│    Leaking: NO (SearchFragment↓ is not leaking)
│    ↓ HashMap.table
├─ java.util.HashMap$Node[] array
│    Leaking: NO (SearchFragment↓ is not leaking)
│    ↓ HashMap$Node[].[3]
├─ java.util.HashMap$Node instance
│    Leaking: NO (SearchFragment↓ is not leaking)
│    ↓ HashMap$Node.value
├─ androidx.fragment.app.FragmentStateManager instance
│    Leaking: NO (SearchFragment↓ is not leaking)
│    ↓ FragmentStateManager.mFragment
├─ org.schabi.newpipe.fragments.list.search.SearchFragment instance
│    Leaking: NO (Fragment#mFragmentManager is not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ SearchFragment.emptyStateView
│                     ~~~~~~~~~~~~~~
├─ android.widget.LinearLayout instance
│    Leaking: UNKNOWN
│    Retaining 4225 bytes in 43 objects
│    View not part of a window view hierarchy
│    View.mAttachInfo is null (view detached)
│    View.mID = R.id.empty_state_view
│    View.mWindowAttachCount = 1
│    mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ LinearLayout.mParent
│                   ~~~~~~~
╰→ android.widget.RelativeLayout instance
​     Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
​     fragments.list.search.SearchFragment received Fragment#onDestroyView()
​     callback (references to its views should be cleared to prevent leaks))
​     Retaining 11112 bytes in 205 objects
​     key = b076c389-4420-4bed-9d6f-a41bc6db2a1d
​     watchDurationMillis = 11120
​     retainedDurationMillis = 1119
​     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

4393 bytes retained by leaking objects
Signature: e94c1e897038acb8f6a52161df3e9d4993eb6c45
┬───
│ GC Root: Global variable in native code
│
├─ android.database.ContentObserver$Transport instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    ↓ ContentObserver$Transport.mContentObserver
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment$1 instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    Anonymous subclass of android.database.ContentObserver
│    ↓ VideoDetailFragment$1.this$0
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment instance
│    Leaking: NO (MainActivity↓ is not leaking and Fragment#mFragmentManager is
│    not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ VideoDetailFragment.activity
├─ org.schabi.newpipe.MainActivity instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking and Activity#mDestroyed
│    is false)
│    mApplication instance of org.schabi.newpipe.DebugApp
│    mBase instance of androidx.appcompat.view.ContextThemeWrapper, not
│    wrapping known Android context
│    ↓ MainActivity.mActivityResultRegistry
├─ androidx.activity.ComponentActivity$2 instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    Anonymous subclass of androidx.activity.result.ActivityResultRegistry
│    this$0 instance of org.schabi.newpipe.MainActivity with mDestroyed = false
│    ↓ ComponentActivity$2.mKeyToCallback
├─ java.util.HashMap instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    ↓ HashMap.table
├─ java.util.HashMap$Node[] array
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    ↓ HashMap$Node[].[4]
├─ java.util.HashMap$Node instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    ↓ HashMap$Node.value
├─ androidx.activity.result.ActivityResultRegistry$CallbackAndContract instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    ↓ ActivityResultRegistry$CallbackAndContract.mCallback
├─ androidx.fragment.app.FragmentManager$11 instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    Anonymous class implementing androidx.activity.result.
│    ActivityResultCallback
│    ↓ FragmentManager$11.this$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│    Leaking: NO (SubscriptionFragment↓ is not leaking)
│    ↓ FragmentManagerImpl.mParent
├─ org.schabi.newpipe.local.subscription.SubscriptionFragment instance
│    Leaking: NO (Fragment#mFragmentManager is not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ SubscriptionFragment._binding
│                           ~~~~~~~~
├─ org.schabi.newpipe.databinding.FragmentSubscriptionBinding instance
│    Leaking: UNKNOWN
│    Retaining 68 bytes in 3 objects
│    ↓ FragmentSubscriptionBinding.rootView
│                                  ~~~~~~~~
╰→ android.widget.RelativeLayout instance
​     Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
​     local.subscription.SubscriptionFragment received Fragment#onDestroyView()
​     callback (references to its views should be cleared to prevent leaks))
​     Retaining 4393 bytes in 100 objects
​     key = b9d2556e-3bbe-4ec1-a6d0-9676b33097cc
​     watchDurationMillis = 35770
​     retainedDurationMillis = 25769
​     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

10060 bytes retained by leaking objects
Signature: ffd68db09531a40e5a1f380bd7d4694ac1d24a
┬───
│ GC Root: Global variable in native code
│
├─ android.database.ContentObserver$Transport instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    ↓ ContentObserver$Transport.mContentObserver
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment$1 instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    Anonymous subclass of android.database.ContentObserver
│    ↓ VideoDetailFragment$1.this$0
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment instance
│    Leaking: NO (MainActivity↓ is not leaking and Fragment#mFragmentManager is
│    not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ VideoDetailFragment.activity
├─ org.schabi.newpipe.MainActivity instance
│    Leaking: NO (BookmarkFragment↓ is not leaking and Activity#mDestroyed is
│    false)
│    mApplication instance of org.schabi.newpipe.DebugApp
│    mBase instance of androidx.appcompat.view.ContextThemeWrapper, not
│    wrapping known Android context
│    ↓ MainActivity.mActivityResultRegistry
├─ androidx.activity.ComponentActivity$2 instance
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    Anonymous subclass of androidx.activity.result.ActivityResultRegistry
│    this$0 instance of org.schabi.newpipe.MainActivity with mDestroyed = false
│    ↓ ComponentActivity$2.mKeyToCallback
├─ java.util.HashMap instance
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    ↓ HashMap.table
├─ java.util.HashMap$Node[] array
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    ↓ HashMap$Node[].[9]
├─ java.util.HashMap$Node instance
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    ↓ HashMap$Node.value
├─ androidx.activity.result.ActivityResultRegistry$CallbackAndContract instance
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    ↓ ActivityResultRegistry$CallbackAndContract.mCallback
├─ androidx.fragment.app.FragmentManager$9 instance
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    Anonymous class implementing androidx.activity.result.
│    ActivityResultCallback
│    ↓ FragmentManager$9.this$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│    Leaking: NO (BookmarkFragment↓ is not leaking)
│    ↓ FragmentManagerImpl.mParent
├─ org.schabi.newpipe.local.bookmark.BookmarkFragment instance
│    Leaking: NO (Fragment#mFragmentManager is not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ BookmarkFragment.emptyStateView
│                       ~~~~~~~~~~~~~~
├─ android.widget.LinearLayout instance
│    Leaking: UNKNOWN
│    Retaining 5301 bytes in 61 objects
│    View not part of a window view hierarchy
│    View.mAttachInfo is null (view detached)
│    View.mID = R.id.empty_state_view
│    View.mWindowAttachCount = 1
│    mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ LinearLayout.mParent
│                   ~~~~~~~
╰→ android.widget.RelativeLayout instance
​     Leaking: YES (ObjectWatcher was watching this because org.schabi.newpipe.
​     local.bookmark.BookmarkFragment received Fragment#onDestroyView()
​     callback (references to its views should be cleared to prevent leaks))
​     Retaining 10060 bytes in 244 objects
​     key = f6a5c998-8493-41eb-900b-3405562e5c32
​     watchDurationMillis = 35769
​     retainedDurationMillis = 25769
​     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

4691 bytes retained by leaking objects
Signature: 5fe849ce30a038be8ff2a51c1ecace8b7d8a6
┬───
│ GC Root: Global variable in native code
│
├─ android.database.ContentObserver$Transport instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    ↓ ContentObserver$Transport.mContentObserver
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment$1 instance
│    Leaking: NO (VideoDetailFragment↓ is not leaking)
│    Anonymous subclass of android.database.ContentObserver
│    ↓ VideoDetailFragment$1.this$0
├─ org.schabi.newpipe.fragments.detail.VideoDetailFragment instance
│    Leaking: NO (MainActivity↓ is not leaking and Fragment#mFragmentManager is
│    not null)
│    activity instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ VideoDetailFragment.activity
├─ 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, not
│    wrapping known Android context
│    ↓ MainActivity.mActivityResultRegistry
├─ androidx.activity.ComponentActivity$2 instance
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    Anonymous subclass of androidx.activity.result.ActivityResultRegistry
│    this$0 instance of org.schabi.newpipe.MainActivity with mDestroyed = false
│    ↓ ComponentActivity$2.mKeyToCallback
├─ java.util.HashMap instance
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    ↓ HashMap.table
├─ java.util.HashMap$Node[] array
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    ↓ HashMap$Node[].[16]
├─ java.util.HashMap$Node instance
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    ↓ HashMap$Node.value
├─ androidx.activity.result.ActivityResultRegistry$CallbackAndContract instance
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    ↓ ActivityResultRegistry$CallbackAndContract.mCallback
├─ androidx.fragment.app.FragmentManager$10 instance
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    Anonymous class implementing androidx.activity.result.
│    ActivityResultCallback
│    ↓ FragmentManager$10.this$0
├─ androidx.fragment.app.FragmentManagerImpl instance
│    Leaking: NO (DefaultKioskFragment↓ is not leaking)
│    ↓ FragmentManagerImpl.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
│    ↓ DefaultKioskFragment.emptyStateView
│                           ~~~~~~~~~~~~~~
├─ android.widget.LinearLayout instance
│    Leaking: UNKNOWN
│    Retaining 4225 bytes in 43 objects
│    View not part of a window view hierarchy
│    View.mAttachInfo is null (view detached)
│    View.mID = R.id.empty_state_view
│    View.mWindowAttachCount = 1
│    mContext instance of org.schabi.newpipe.MainActivity with mDestroyed =
│    false
│    ↓ LinearLayout.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 4691 bytes in 108 objects
​     key = 637b3418-1759-4543-a956-a0ee228bebc4
​     watchDurationMillis = 35770
​     retainedDurationMillis = 25769
​     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
====================================
METADATA

Please include this in bug reports and Stack Overflow questions.

Build.VERSION.SDK_INT: 30
Build.MANUFACTURER: Google
LeakCanary version: 2.5
App process name: org.schabi.newpipe.debug
Stats: LruCache[maxSize=3000,hits=9464,misses=169551,hitRate=5%]
RandomAccess[bytes=9770935,reads=169551,travel=73954410254,range=35575780,size=4
4473740]
Analysis duration: 8037 ms
Heap dump file path: /storage/emulated/0/Download/leakcanary-org.schabi.newpipe.
debug/2021-12-03_16-27-31_563.hprof
Heap dump timestamp: 1638545264414
Heap dump duration: 4440 ms
====================================

@litetex
Copy link
Member

litetex commented Dec 3, 2021

How can I find a debug log?

Use logcat which is shipped with ADB

There are a bunch of manuals available online (searching for android get logs returns some good results), e.g:

@Gill-Grmn
Copy link
Author

Gill-Grmn commented Dec 3, 2021

Use logcat which is shipped with ADB

There was some logging, see the following (zipped) *.hprof file and screenshot:

2021-12-03_16-27-31_563.zip

Is this helpfull?

@litetex
Copy link
Member

litetex commented Dec 4, 2021

Is this helpfull?

TL;DR
No.

These are not logs but that's a HeapDump file in that zip.
A HeapDump represents all currently loaded things of the app inside the RAM (summarized).
LeakCanary - which your are using - is a tool for developers to find memory leaks. However the things you found are likely false positives.

So at first I think that RAM usage of NewPipe is not related to the fact that it is slow. At least in that use-case so far and without logs.

There was some logging

Please send in the logs (when it's slow).

@Gill-Grmn
Copy link
Author

How can I find a debug log?

Use logcat which is shipped with ADB

There are a bunch of manuals available online (searching for android get logs returns some good results), e.g:

I would really like to do that. But for me as non-developer installing a debuging environment as decribed above is too complicated for me and I don't have the knowlegde for doing it. If there is anything else/ less complicated I can do to support narrowing down the cause of my Newpipe-handbrake, then please let me know.

@litetex litetex added bug Issue is related to a bug more info needed template missing The bug/feature template is missing (e.g. the used app does not support issue templates) labels Dec 6, 2021
@ctd42

This comment was marked as off-topic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Issue is related to a bug device/software specific Issues that only happen on some devices or with some specific hardware/software template missing The bug/feature template is missing (e.g. the used app does not support issue templates)
Projects
None yet
Development

No branches or pull requests

5 participants