opusforlife2
commented
1 year ago Try using mobile data instead of wifi.
Closed OldGuyInTheClub closed 8 months ago
opusforlife2
commented
1 year ago Try using mobile data instead of wifi.
OldGuyInTheClub
commented
1 year ago Problem exists with both mobile data and Wifi. Seems worse with mobile.
opusforlife2
commented
1 year ago And do you see this occur if you follow the steps in #9030?
OldGuyInTheClub
commented
1 year ago I get the crashes without having to change speeds or sizes as in that Issue. I don't get a popup that the app is not responding. I get the "Sorry that should not have happened" crash with diagnostics.
MoralCode
commented
1 year ago I believe i am seeing the same thing. my device and crash log is nearly identical as far as I can tell.
{"user_action":"ui error","request":"ACRA report","content_language":"en-US","content_country":"US","app_language":"en_US","service":"none","package":"org.schabi.newpipe","version":"0.24.1","os":"Linux samsung/beyond0qltesq/beyond0q:12/SP1A.210812.016/G970USQU7IVH3:user/release-keys 12 - 31","time":"2023-01-11 23:34","exceptions":["android.app.ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{b232cc4 u0 org.schabi.newpipe/.player.PlayerService}\n\tat android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:2147)\n\tat android.app.ActivityThread.access$2900(ActivityThread.java:310)\n\tat android.app.ActivityThread$H.handleMessage(ActivityThread.java:2376)\n\tat android.os.Handler.dispatchMessage(Handler.java:106)\n\tat android.os.Looper.loopOnce(Looper.java:226)\n\tat android.os.Looper.loop(Looper.java:313)\n\tat android.app.ActivityThread.main(ActivityThread.java:8663)\n\tat java.lang.reflect.Method.invoke(Native Method)\n\tat com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:567)\n\tat com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1135)\n"],"user_comment":"this keeps happening when google maps is open and navigating somewhere. it takes over my screen and is dangerous for drivers."}
initially tried to send via email but the email address doesnt seem to exist anymore.
Device: Samsung S10E Android Ver: 12, same kernel version 4.14.190 - stock, no custom ROM, no root, phone does have developer mode enabled if that means anything.
My primary observation is that I almost never see this error during daily use (i.e. when im intending to use the newpipe app), but it only seemed to appear when i was trying to navigate somewhere in google maps. This error will take over the screen reducing the map to a picture in picture view and then cover that up with a system pipup like "it looks like newpipe crashed" with options to stop the app or wait (or maybe clear cache, i forget).
nothing i have tried (including stopping the app from that prompt, waiting for the app, killing the app from task switcher, clearing the cache, force stopping the app, uninstalling and reinstalling) seems to have worked to fix this.
Personally I feel as though this is potentially a danger to drivers and may warrant toning down how aggressively the crash reporting wants to be on screen if an error occurs while the app or any of its windows (like picture in picture) aren't visible on screen.
MoralCode
commented
1 year ago Here is a screenshot of what i see when this happens:
OldGuyInTheClub
commented
1 year ago I'm still experiencing this, as well. The problem appears to correlate moderately with connecting to or switching between networks such as wifi->cellular or cellular->cellular handoff. Might not be exclusive to that though. I remembered an earlier ticket I filed with a similar issue when I had an LGV20 phone and Sprint service: https://github.com/TeamNewPipe/NewPipe/issues/6012 That got fixed when Sprint, my provider at the time, pushed some kind of update.
But, now I have a Samsung phone and a T-Mobile SIM card. I don't know if I am on legacy Sprint network hardware or if I am fully on T-Mobile. Whatever the case, Newpipe worked very well with the Samsung until v24.
I have looked all over the Samsung phone to see if there are any network/connectivity settings I could invoke to further troubleshoot this but have not found anything. There are no applicable phone or network updates, either.
Question: Does NewPipe expect specific behaviors of connectivity or connection changes from the phone/ISP/whatever that may not be satisfied? That might help me dig specifically into my phone settings. The prior ticket got resolved by some miracle fix at the cellular system level. I have no idea if lightning will strike twice there.
(Updated to correct spelling errors and for clarifications)
MoralCode
commented
1 year ago the changing networks theory kind of fits with my experience of the error too, since when im using google maps, im usually traveling, but this doesnt seem to always recreate the issue.
id be curious if these reproduction steps work to resolve the issue:
given that the error i observed seems to be relating to some background task, i assume it would happen if the app was playing a video in the background and either lost network while playing, it would get into a state where it could (in theory) keep spitting out this error whenever the network changes.
This also seems related to a different error i see this fairly often when using the app in the foreground. It happens when i resume watching a video that was started a previous day and run out of buffered video that was loaded the day before. That said, this results in a different, notification + toast style of error and never really looked into it so it may not be the same.
Edit: this other kind of error seems to already be documented in https://github.com/TeamNewPipe/NewPipe/issues/10174
When this other error happens I usually just back out of the video and re open it to cause it to pick up from where I was with no issues. Maybe the bug in this issue is the background equivalent of this other foreground-oriented version i have been noticing?
OldGuyInTheClub
commented
1 year ago I agree that it may not be the definitive cause but might help narrow the possibilities.
I'll try your steps over the next few days and report back.
Resuming play after a long time: I have trouble with this although I usually don't get a crash. Often the video just spins until I click the 'x' to stop it and restart the video and/or restart Newpipe and then the video - both from time zero.
RandomStuf6
commented
1 year ago I have been having the same issues since 0.24.0. I have tried on both Lineage OS 19.1 and 20, and having only gotten 20 recently, the problem only seems worse with the not responding popup happening repeatedly every couple of seconds when it starts, rather than only every so often. It seems to be an issue with background usage and opening other apps, as it seems like if i switch off newpipe for a while and try go back on it, it crashes, and if I try use the background player that also often causes it to crash.
EthanZeigler
commented
1 year ago I'm also getting this stack trace but can consistently replicate it. Open a pop-up player, tap on a timestamp in a comment, then pull the pop up player to the close icon. App crashes with that same trace.
MoralCode
commented
1 year ago I'll try your steps over the next few days and report back.
@OldGuyInTheClub any results? I'd love to root-cause this if possible in case that reveals that the fix is something simple that i can just throw up a PR and/or dev build for to have people test
OldGuyInTheClub
commented
1 year ago I'll try your steps over the next few days and report back.
@OldGuyInTheClub any results? I'd love to root-cause this if possible in case that reveals that the fix is something simple that i can just throw up a PR and/or dev build for to have people test
I'm very sorry - I haven't had a chance to test your steps yet. Just today I updated to the latest 0.25.0. Still getting a crash when the phone loses connection with my home wifi and finds the cellular network. I don't normally use Google Maps but, FWIW, I didn't see the issue while using Waze (Google product) but this is an observation and not a full-on test.
I wonder if it has something to do with how the phone/apps handle interruptions whether it is in the network connection or not. I have another music app that will randomly disconnect on me even when there is a good signal. There are so many services going on in the background that resource conflicts may be unavoidable. There is not too much traffic on this issue so maybe there's some weird mix of circumstances affecting us but not others.
goat-oss
commented
1 year ago I'm getting the same error. The app crashes randomly after a video `ends.
`## Exception
android.app.ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{a5f1d39 u0 org.schabi.newpipe/.player.PlayerService}
at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:2152)
at android.app.ActivityThread.access$2900(ActivityThread.java:315)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2381)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:226)
at android.os.Looper.loop(Looper.java:313)
at android.app.ActivityThread.main(ActivityThread.java:8751)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:571)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1135)
`
EthanZeigler
commented
1 year ago I'd like to add, I suspect something changed in Android or Google play services. I have multiple apps complaining of being unable to start background processes, including ones where battery optimization is off. Seems by this thread I'm not the only one
MoralCode
commented
1 year ago Actually now that you point that out, im reminded of https://dontkillmyapp.com/. They seem to be on top of these kinds of changes and may have more info about this problem
MoralCode
commented
1 year ago Possibly better, easier to reproduce steps that get the app to crash:
my suspicion/theory as to why this happens is that some network connection becomes stale/disconnected and the app tries to reuse a now-stale connection when attempting to download more video to add to the buffer
EthanZeigler
commented
1 year ago I found an even better method to the above. Play the video in pop-up mode and open another app. Let the buffer become empty and the video will freeze up completely with a network error and/or the background error
OldGuyInTheClub
commented
1 year ago Could this be solved in principle by having a "Download and enqueue" feature so videos would play from local storage? I know this requires coding but it may be easier than trying to fix something deep in the gizzards affecting only a few users.
I can submit a Feature Request if appropriate.
MoralCode
commented
1 year ago Maybe? I guess? Most if it exists already with the download feature tho.
I found an even better method to the above. Play the video in pop-up mode and open another app. Let the buffer become empty and the video will freeze up completely with a network error and/or the background error
Tried this and couldn't reproduce it. Do you have more info on how you tested this?
EthanZeigler
commented
1 year ago Maybe? I guess? Most if it exists already with the download feature tho.
I found an even better method to the above. Play the video in pop-up mode and open another app. Let the buffer become empty and the video will freeze up completely with a network error and/or the background error
Tried this and couldn't reproduce it. Do you have more info on how you tested this?
Nope, just exactly like that. Nothing special.
Man this is a weird bug we've found.
OldGuyInTheClub
commented
1 year ago Maybe? I guess? Most if it exists already with the download feature tho. ...
I can definitely download files and play them in an external player. This would be a convenience to stay within one app. I'll submit a feature request and see where it goes.
MoralCode
commented
1 year ago @EthanZeigler Do you think you could try reproducing my method if you have a chance to do so overnight tonight? im curious if it reproduces more reliably on other devices or if we are really looking at two different issues
av01d1ngx4
commented
1 year ago Beginning with Android Oreo (API level 26), the system imposes a new policy requiring a foreground service to display a notification telling the user that the app is executing a foreground service. This policy is intended to prevent programs from running in the background for extended periods of time and consuming excessive system resources.
MoralCode
commented
1 year ago Small breakthrough- got a similar looking error when clicking the "play" button on my headphones.
On Android;
I can try and reproduce this again later since it only happened once and may still be a coincidence. Maybe this idea helps someone tho
EthanZeigler
commented
1 year ago @MoralCode can confirm, this consistently replicates it.
MoralCode
commented
1 year ago Cool! Now where in the code is the play/pause action handled?
CHanoey145
commented
1 year ago android.app.RemoteServiceException$ForegroundServiceDidNotStartInTimeException: Context.startForegroundService() did not then call Service.startForeground(): ServiceRecord{b8511a6 u0 org.schabi.newpipe/.player.PlayerService}
at android.app.ActivityThread.generateForegroundServiceDidNotStartInTimeException(ActivityThread.java:2009)
at android.app.ActivityThread.throwRemoteServiceException(ActivityThread.java:1983)
at android.app.ActivityThread.-$$Nest$mthrowRemoteServiceException(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2245)
at android.os.Handler.dispatchMessage(Handler.java:106)
at android.os.Looper.loopOnce(Looper.java:201)
at android.os.Looper.loop(Looper.java:288)
at android.app.ActivityThread.main(ActivityThread.java:7903)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:548)
at com.android.internal.os.ExecInit.main(ExecInit.java:49)
at com.android.internal.os.RuntimeInit.nativeFinishInit(Native Method)
at com.android.internal.os.RuntimeInit.main(RuntimeInit.java:355)
Caused by: android.app.StackTrace: Last startServiceCommon() call for this service was made here
at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1936)
at android.app.ContextImpl.startForegroundService(ContextImpl.java:1891)
at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:822)
at android.content.ContextWrapper.startForegroundService(ContextWrapper.java:822)
at androidx.core.content.ContextCompat$Api26Impl$$ExternalSyntheticApiModelOutline0.m(R8$$SyntheticClass:0)
at androidx.core.content.ContextCompat$Api26Impl.startForegroundService(ContextCompat.java:931)
at androidx.core.content.ContextCompat.startForegroundService(ContextCompat.java:703)
at androidx.media.session.MediaButtonReceiver.onReceive(MediaButtonReceiver.java:115)
at android.app.ActivityThread.handleReceiver(ActivityThread.java:4311)
at android.app.ActivityThread.-$$Nest$mhandleReceiver(Unknown Source:0)
at android.app.ActivityThread$H.handleMessage(ActivityThread.java:2157)
... 9 more
I'm getting same error again and again. I'm using graphene os
CHanoey145
commented
1 year ago I think tracker control (VPN) caused it in my phone
OldGuyInTheClub
commented
11 months ago Revisiting this issue which has improved in that I don't get infinite crash loops but where crashes regularly occur reasonably correlated with network changes.
I suspect that this is not a NewPipe problem so much as how NewPipe interacts with my phone and/or service provider.
If appropriate, I'd like to ask for ideas on what to look for on my phone. e.g. If NewPipe expects certain behaviors from the phone's "stack" I can try to dig into Android/Samsung/T-Mobile resources to see if they're non-compliant somewhere. Maybe an OS update broke something, maybe something on the network side is misconfigured.
I'm not well-versed in any of this but am willing to learn and would appreciate some ideas of where to begin.
MoralCode
commented
11 months ago I think I've been seeing an increase in the number of crashes lately, but also I've noticed that it doesn't always seem to correlate with obvious network problems. The downloader seems more reliable (although that has errored a few times too). Maybe (if streaming uses UDP) the app isn't quite as able to handle packet loss so a temporary latency spike or dropped packet causes a crash?
OldGuyInTheClub
commented
11 months ago That sounds plausible although I am not well-versed in the details. If it is UDP, it seems like there would be some standardized way of dealing with dropped packets.
My issues started with v0.24 and subsequent updates have had more or fewer crashes but never the stable performance before. Since this isn't a huge issue with the user base, it is a few of us having hard-to-quantify crashes. Therefore, I'm looking at what I could do on the phone and/or the network side.
One possibility is that NewPipe expects phones to conform to some requirements. As a guess, let's say it expects to have priority over other apps in case of glitches. Perhaps my phone was borderline until NewPipe v0.24 and then on the wrong side after. Or, I went to a my Galaxy S10+ and a T-Mobile SIM after they bought Sprint and obsoleted my LG V20. Could be something on the network side if they're still assimilating old Sprint networks.
But, danged if I know how to explore any of these SWAGs. I suppose I could back up the phone, do a factory reset, and start over or switch to a different provider.
MoralCode
commented
11 months ago The provider thing seems super overkill. Im on AT&T so i dont think its a specific carriers fault. I imagine newpipe just assumes a more reliable network than moat people actually get. Maybe its worth finding some development tools that simulate different network qualities/amounts of packet loss and try to use newpipe over that.
Also did any of the reproduction steps i posted about previously help?
OldGuyInTheClub
commented
11 months ago Sometimes the steps did cause the problem, sometimes not. I get crashes 3 out of 4 times when I leave my house's wifi and get connected to cellular data. I'll put my phone on airplane mode at work to focus (cellular data). When I reenable it, I have a high chance of getting a crash. NewPipe doesn't even have to be running, just started. The error screen will come to the foreground. The problem occurs more on cellular data than on wifi although it does happen on both.
Edit: I will see if my home wifi router will let me throttle the link speed to simulate network problems
MoralCode
commented
11 months ago Actually, it looks like the recent errors im seeing are 403 "source error" errors. This may fall under a different issue so i wont post an error here as it may confuse future searchers. maybe its part of their new policy where you only get to watch three videos with adblock before you are prevented from continuing?
opusforlife2
commented
11 months ago Could you guys ensure that the description is updated with the latest, most reliable STR?
OldGuyInTheClub
commented
11 months ago What is an STR?
MoralCode
commented
11 months ago What is an STR?
idk, probably the same concept as reproduction steps though.
EthanZeigler
commented
11 months ago String (the exact version number, letters included)
On Sun, Aug 6, 2023, 7:38 PM Adrian Edwards @.***> wrote:
What is an STR?
idk, probably the same concept as reproduction steps though.
— Reply to this email directly, view it on GitHub https://github.com/TeamNewPipe/NewPipe/issues/9358#issuecomment-1667005541, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACFTL6AID6Z3AZSVHJJTQETXUATGHANCNFSM6AAAAAAR4EQJXU . You are receiving this because you were mentioned.Message ID: @.***>
OldGuyInTheClub
commented
11 months ago What is an STR?
idk, probably the same concept as reproduction steps though.
Ah, Steps To Reproduce perhaps. I have done so.
MoralCode
commented
11 months ago i concur with the 0.24.1 reproducible version already in there - ive had issues on more recent versions, but they most likely aren't the same issue. Although i think the player in that version has been broken due to youtube constantly changing things, so it may not even be usable for testing this anyway since most of the repro steps rely on actually loading content.
@opusforlife2 are you aware of any changes in versions since 0.24.1 that would make the app more reliable under changing network conditions?
OldGuyInTheClub
commented
11 months ago I left the original report for 0.24.1 as-is and added an update.
opusforlife2
commented
11 months ago No specific change or changes. But a lot of things get refactored in newer versions, so it's worth testing.
godfuture
commented
11 months ago the changing networks theory kind of fits with my experience of the error too, since when im using google maps, im usually traveling, but this doesnt seem to always recreate the issue.
Edit: here is the error report for this other kind of error. LMK if I should move this to a new issue to avoid cluttering things here.
{"user_action":"play stream","request":"Player error[type=ERROR_CODE_IO_BAD_HTTP_STATUS] occurred while playing https://www.youtube.com/watch?v=bew4pBYmTFI","content_language":"en-US","content_country":"US","app_language":"en_US","service":"YouTube","package":"org.schabi.newpipe","version":"0.24.1","os":"Linux samsung/beyond0qltesq/beyond0q:12/SP1A.210812.016/G970USQU7IVH3:user/release-keys 12 - 31","time":"2023-01-22 22:49","exceptions":["com.google.android.exoplayer2.ExoPlaybackException: Source error\n\tat com.google.android.exoplayer2.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:632)\n\tat com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:604)\n\tat android.os.Handler.dispatchMessage(Handler.java:102)\n\tat android.os.Looper.loopOnce(Looper.java:226)\n\tat android.os.Looper.loop(Looper.java:313)\n\tat android.os.HandlerThread.run(HandlerThread.java:67)\nCaused by: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeException: Response code: 403\n\tat org.schabi.newpipe.player.datasource.YoutubeHttpDataSource.open(YoutubeHttpDataSource.java:422)\n\tat com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:258)\n\tat com.google.android.exoplayer2.upstream.TeeDataSource.open(TeeDataSource.java:52)\n\tat com.google.android.exoplayer2.upstream.cache.CacheDataSource.openNextSource(CacheDataSource.java:786)\n\tat com.google.android.exoplayer2.upstream.cache.CacheDataSource.open(CacheDataSource.java:599)\n\tat com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:84)\n\tat com.google.android.exoplayer2.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:124)\n\tat com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:412)\n\tat java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)\n\tat java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)\n\tat java.lang.Thread.run(Thread.java:920)\n"],"user_comment":""}When this happens I usually just back out of the video and re open it to cause it to pick up from where I was with no issues. Maybe the bug in this issue is the background equivalent of this other foreground-oriented version i have been noticing?
I think this a good theory. I have the same error from time to time. In my case I think the disconnect happens because I have two access points with same SSID and my phone dictates the roaming strategy. Means, I cannot influence when my phone will switch from 2,4 GHz to 5 GHz network and vise versa. The same would happen, if the phone is switching from wifi to mobile network sitting in train, or having short interrupt in mobile network.
It would be super nice, if NewPipe was more resilient against network interrupts.
godfuture
commented
11 months ago I think this a good theory. I have the same error from time to time. In my case I think the disconnect happens because I have two access points with same SSID and my phone dictates the roaming strategy. Means, I cannot influence when my phone will switch from 2,4 GHz to 5 GHz network and vise versa. The same would happen, if the phone is switching from wifi to mobile network sitting in train, or having short interrupt in mobile network.
It would be super nice, if NewPipe was more resilient against network interrupts.
I have to correct the statement a bit. Now I had more time monitoring it and I noticed the app crashes with 403 even without network changes. Like this the app is close to unusable because after crash I cannot resume the video. I always have to force close the app and restart the video..but for how many minutes of playtime?
MoralCode
commented
11 months ago the 403 error might be off topic for this issue (or tangentially related at best) and it was my mistake for mentioning it in this issue - here is the issue tracking that specific problem: https://github.com/TeamNewPipe/NewPipe/issues/10174
taking a surface-level look at some of the other issues that it links to does seem to suggest a certain similarity to the symptoms discovered here (vaguely related to network changes, but also happening on a stable network). The devs may be more equipped to examine the true causes than I am though
OldGuyInTheClub
commented
10 months ago Checking in again to see if there are any insights on why this problem could have started with v24.0 after working with prior versions. The Releases page shows a number of changes incorporated into v24.0 but I have no idea if any/any combination of them could be responsible.
Alternately, I'm comfortable with closing this issue if there is no alternative but to live with/work around the crashes.
AudricV
commented
10 months ago I think I found the cause of the issue.
The player service seems to be only started in the foreground after playback has been initialized (so after the ExoPlayer instance is created and probably after stream info is loaded).
If this process takes a lot of time, a ForegroundServiceDidNotStartInTimeException on Android 12 and higher exception should be thrown by the system and a RemoteServiceException between Android 8.0 and Android 11 versions, due to restrictions on foreground services introduced with Android 8.0. Both exceptions have in their message Context.startForegroundService() did not then call Service.startForeground(). See https://developer.android.com/reference/android/content/Context#startForegroundService(android.content.Intent) for more details.
This issue was also present in the past and has been resolved with https://github.com/TeamNewPipe/NewPipe/commit/fbcdaa77e317ffcdaf57ec7bf2248751127d5b67.
In 0.23.3, the notification was created and the service was putted in the foreground state before handling the intent which started playback in the player, see the following code: https://github.com/TeamNewPipe/NewPipe/blob/4227866fcfc852b57aabfe03bf458e69e5a050ca/app/src/main/java/org/schabi/newpipe/player/MainPlayer.java#L109
The fix was then removed in 0.24.0: see https://github.com/TeamNewPipe/NewPipe/commit/76ced59b62322537eb818cd3fea7ddd1b9c2d711#diff-a9f8070f8db88aff3228ca5d69babc66fc7dd3df469e1cdc935ce426aea20178L109.
So the issue should be fixed by reintroducing the creation of the player service notification and starting the player service in foreground before handling intents in the player.
This would also reintroduce the ghost notification when you use a media button on an external device such as a Bluetooth one and NewPipe was the last media app used. I think the issue can be resolved by stopping the player service when there is nothing to play and a media button receiver intent is received.
The following patch should solve the issue and the one I described which would come back:
Subject: [PATCH] Create notification and start player service in foreground when creating in the player
This behavior was present before 0.24.0 and the player UI separation and
avoided crashes for which their exception contained
"Context.startForegroundService() did not then call Service.startForeground()".
Some player nullability checks have been also added.
---
Index: app/src/main/java/org/schabi/newpipe/player/notification/NotificationPlayerUi.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/app/src/main/java/org/schabi/newpipe/player/notification/NotificationPlayerUi.java b/app/src/main/java/org/schabi/newpipe/player/notification/NotificationPlayerUi.java
--- a/app/src/main/java/org/schabi/newpipe/player/notification/NotificationPlayerUi.java (revision b5463cf5e14e9b98cb97744cc3dfb5e34a315259)
+++ b/app/src/main/java/org/schabi/newpipe/player/notification/NotificationPlayerUi.java (date 1694718257649)
@@ -17,7 +17,6 @@
import org.schabi.newpipe.player.ui.PlayerUi;
public final class NotificationPlayerUi extends PlayerUi {
- private boolean foregroundNotificationAlreadyCreated = false;
private final NotificationUtil notificationUtil;
public NotificationPlayerUi(@NonNull final Player player) {
@@ -25,15 +24,6 @@
notificationUtil = new NotificationUtil(player);
}
- @Override
- public void initPlayer() {
- super.initPlayer();
- if (!foregroundNotificationAlreadyCreated) {
- notificationUtil.createNotificationAndStartForeground();
- foregroundNotificationAlreadyCreated = true;
- }
- }
-
@Override
public void destroy() {
super.destroy();
@@ -122,4 +112,8 @@
super.onPlayQueueEdited();
notificationUtil.createNotificationIfNeededAndUpdate(false);
}
+
+ public void createNotificationAndStartForeground() {
+ notificationUtil.createNotificationAndStartForeground();
+ }
}
Index: app/src/main/java/org/schabi/newpipe/player/PlayerService.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/app/src/main/java/org/schabi/newpipe/player/PlayerService.java b/app/src/main/java/org/schabi/newpipe/player/PlayerService.java
--- a/app/src/main/java/org/schabi/newpipe/player/PlayerService.java (revision b5463cf5e14e9b98cb97744cc3dfb5e34a315259)
+++ b/app/src/main/java/org/schabi/newpipe/player/PlayerService.java (date 1694718373526)
@@ -29,6 +29,7 @@
import android.util.Log;
import org.schabi.newpipe.player.mediasession.MediaSessionPlayerUi;
+import org.schabi.newpipe.player.notification.NotificationPlayerUi;
import org.schabi.newpipe.util.ThemeHelper;
import java.lang.ref.WeakReference;
@@ -59,6 +60,13 @@
ThemeHelper.setTheme(this);
player = new Player(this);
+
+ // Create the player notification and start immediately the service in foreground,
+ // otherwise if nothing is played or initializing the player and its components (especially
+ // loading stream metadata) takes a lot of time, the app would crash on Android 8+ as the
+ // service would never be put in the foreground while we said to the system we would do so
+ player.UIs().get(NotificationPlayerUi.class)
+ .ifPresent(NotificationPlayerUi::createNotificationAndStartForeground);
}
@Override
@@ -69,9 +77,11 @@
}
if (Intent.ACTION_MEDIA_BUTTON.equals(intent.getAction())
- && player.getPlayQueue() == null) {
- // No need to process media button's actions if the player is not working, otherwise the
- // player service would strangely start with nothing to play
+ && (player == null || player.getPlayQueue() == null)) {
+ // No need to process media button's actions if the player is not working, otherwise
+ // the player service would strangely start with nothing to play
+ // Stop the service in this case
+ stopSelf();
return START_NOT_STICKY;
}
@@ -87,7 +97,7 @@
Log.d(TAG, "stopForImmediateReusing() called");
}
- if (!player.exoPlayerIsNull()) {
+ if (player != null && !player.exoPlayerIsNull()) {
// Releases wifi & cpu, disables keepScreenOn, etc.
// We can't just pause the player here because it will make transition
// from one stream to a new stream not smooth
@@ -98,7 +108,7 @@
@Override
public void onTaskRemoved(final Intent rootIntent) {
super.onTaskRemoved(rootIntent);
- if (!player.videoPlayerSelected()) {
+ if (player != null && !player.videoPlayerSelected()) {
return;
}
onDestroy();I built a debug APK with these changes based on b1ab2618908db73f6df778b4872f242940b3873a, could you test if it fixes the issue? Thanks in advance.
OldGuyInTheClub
commented
10 months ago This is terrific! I don't understand the details but I think I follow the argument at the proverbial 100-kft level.
@AudricV : Is it me you would like to test this fix or the devs? If me, can you let me know how best to proceed? Should I:
Thank you for your deep dive into this problem.
AudricV
commented
10 months ago @OldGuyInTheClub Yes, I ask you to test this debug build, importing existing settings and database shouldn't matter, but please do so to be sure the problem doesn't happen with existing data.
You don't need to uninstall the official release of the app.
Checklist
Affected version
0.24.1 (but also saw in 0.24)
Steps to reproduce the bug
UPDATED 6 August 2023 with v0.25.2
or
Change in behavior: Guru Meditation error no longer goes into infinite loop. Still steals focus as always but it is possible to swipe dismiss the app and restart. Usually it will work for a while after one or two restarts and then the problem happens again
Expected behavior
App used to work great. Started having this problem with 0.24. Hoped 0.24.1 would fix it but didn't
Actual behavior
Regular crashes
Screenshots/Screen recordings
No response
Logs
Exception
Crash log
Affected Android/Custom ROM version
Android 12 4.14.190 - stock, no custom ROM, no root
Affected device model
Samsung Galaxy S10+, US T Mobile
Additional information
Closest relevant recent Open Issue is https://github.com/TeamNewPipe/NewPipe/issues/9163 but my problem doesn't happen immediately on startup.
Closest Closed Issue is https://github.com/TeamNewPipe/NewPipe/issues/9339 but afaik, there isn't a fix (looked at other referenced Issues)
Steps tried.
Delay between app start and crash not perfectly reproducible. Occasionally it will be stable for a few minutes but once a crash happens, it will repeat 10-15 seconds after every restart for some time after which it will be stable for a little while before starting the quick crash pattern
Problem is not affected by VPN state
Weak correlation with signal strength: Wifi connections appear to take longer between crashes relative to cellular network. Can't prove it. Just an observation.
I don't have the tools or skill to get any bug report beyond the Guru Meditation dump provided in the Logs box