[Nightly] Closed videos are stuck in notifications

[macpluscheese]

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.27.7-1031

Steps to reproduce the bug

1. Open any video
2. Close said video
3. See video is still in notifications

Expected behavior

Video is removed from notifications

Actual behavior

Video stays in notifications, opening and closing more videos adds even more ghost videos

Screenshots/Screen recordings

Logs

No response

Affected Android/Custom ROM version

Android 11 - Stock

Affected device model

ZTE Blade A51

Additional information

Ghost videos cannot be interacted with, had to reboot phone to remove notification.

[ShareASmile]

Affected Android/Custom ROM version

No response

Affected device model

No response

1.) As you have not filled necessary info in relevant sections of the issue, may i ask about missing info here about your device & its android version. It can be relevant to diagnose the issue. You can edit the issue to update your device details.

2.) Have you tried some older versions of NewPipe nightly to ascertain from which version this problem started occurring?

If you want to help out then please start testing from nightly 1030 to higher versions updating step-by-step and post your findings here.

[macpluscheese]

1.) As you have not filled necessary info in relevant sections of the issue, may i ask about missing info here about your device & its android version. It can be relevant to diagnose the issue. You can edit the issue to update your device details.

2.) Have you tried some older versions of NewPipe nightly to ascertain from which version this problem started occurring?

If you want to help out then please start testing from nightly 1030 to higher versions updating step-by-step and post your findings here.

Hello, I edited the original post to include the infomation you requested. I also found 1031 was the earliest version which had this bug, 1030 didn't.

[ShareASmile]

Thanks for confirming, this bug pin points to support for Android Auto PR #12044.

[Stypox]

This diff resolves the bug, but the reason why it does remains a mystery. It is basically a revert of 064e1d3. However, it disables the MediaBrowser, meaning Android Auto will not work, so I now need to resolve the mystery. Do I love Android's mysteries!

diff --git a/app/src/main/java/org/schabi/newpipe/player/PlayerService.java b/app/src/main/java/org/schabi/newpipe/player/PlayerService.java
index 1888bce01..b251868df 100644
--- a/app/src/main/java/org/schabi/newpipe/player/PlayerService.java
+++ b/app/src/main/java/org/schabi/newpipe/player/PlayerService.java
@@ -94,7 +94,7 @@ public final class PlayerService extends MediaBrowserServiceCompat {
         assureCorrectAppLanguage(this);
         ThemeHelper.setTheme(this);
 
-        mediaBrowserImpl = new MediaBrowserImpl(this, this::notifyChildrenChanged);
+//        mediaBrowserImpl = new MediaBrowserImpl(this, this::notifyChildrenChanged);
 
         // see https://developer.android.com/training/cars/media#browser_workflow
         mediaSession = new MediaSessionCompat(this, "MediaSessionPlayerServ");
@@ -102,17 +102,17 @@ public final class PlayerService extends MediaBrowserServiceCompat {
         sessionConnector = new MediaSessionConnector(mediaSession);
         sessionConnector.setMetadataDeduplicationEnabled(true);
 
-        mediaBrowserPlaybackPreparer = new MediaBrowserPlaybackPreparer(
-                this,
-                sessionConnector::setCustomErrorMessage,
-                () -> sessionConnector.setCustomErrorMessage(null),
-                (playWhenReady) -> {
-                    if (player != null) {
-                        player.onPrepare();
-                    }
-                }
-        );
-        sessionConnector.setPlaybackPreparer(mediaBrowserPlaybackPreparer);
+//        mediaBrowserPlaybackPreparer = new MediaBrowserPlaybackPreparer(
+//                this,
+//                sessionConnector::setCustomErrorMessage,
+//                () -> sessionConnector.setCustomErrorMessage(null),
+//                (playWhenReady) -> {
+//                    if (player != null) {
+//                        player.onPrepare();
+//                    }
+//                }
+//        );
+//        sessionConnector.setPlaybackPreparer(mediaBrowserPlaybackPreparer);
 
         // Note: you might be tempted to create the player instance and call startForeground here,
         // but be aware that the Android system might start the service just to perform media
@@ -213,9 +213,9 @@ public final class PlayerService extends MediaBrowserServiceCompat {
 
         cleanup();
 
-        mediaBrowserPlaybackPreparer.dispose();
+        //mediaBrowserPlaybackPreparer.dispose();
         mediaSession.release();
-        mediaBrowserImpl.dispose();
+        //mediaBrowserImpl.dispose();
     }
 
     private void cleanup() {
@@ -331,7 +331,7 @@ public final class PlayerService extends MediaBrowserServiceCompat {
                                  final int clientUid,
                                  @Nullable final Bundle rootHints) {
         // TODO check if the accessing package has permission to view data
-        return mediaBrowserImpl.onGetRoot(clientPackageName, clientUid, rootHints);
+        return null;// mediaBrowserImpl.onGetRoot(clientPackageName, clientUid, rootHints);
     }
 
     @Override

[Stypox]

So apparently the problem is onGetRoot always returning a BrowserRoot instance. Making it return null solved the issue (but again, breaks Android Auto compatibility). It turns out (see stack overflow) that onGetRoot is also used for media resumption, which causes a new notification to pop up (in this case a useless notification because our onGetRoot does not return something that can be used for resumption). So what needs to be done is to check if rootHints?.getBoolean(EXTRA_RECENT) == true and if that's the case not return anything (as EXTRA_RECENT is used by the system for resumption).