Newpipe: Crash when running two newpipe instances at the same time: java.lang.RuntimeException: Error receiving broadcast intent…

[B0pol]

Checklist

• [x] I am using the latest version - 0.20.1
• [x] I checked, but didn't find any duplicates (open OR closed) of this issue in the repo.
• [x] I have read the contribution guidelines given at https://github.com/TeamNewPipe/NewPipe/blob/HEAD/.github/CONTRIBUTING.md.
• [x] This issue contains only one bug. I will open one issue for every bug report I want to file.

Steps to reproduce the bug

• (optional?) uninstall all newpipe apps
• install newpipe 0.20.1
• install a newpipe debug version, to have multiple newpipes at the same time
• open a video

Actual behaviour

Crash

Expected behavior

Everything works fine

Logs

Exception

• __User Action:__ ui error
• __Request:__ App crash, UI failure
• __Content Country:__ FR
• __Content Language:__ fr-FR
• __App Language:__ fr_FR
• __Service:__ none
• __Version:__ 0.20.1
• __OS:__ Linux Android 9 - 28
  
  Crash log

java.lang.RuntimeException: Error receiving broadcast Intent { act=org.schabi.newpipe.VideoDetailFragment.ACTION_PLAYER_STARTED flg=0x10 } in org.schabi.newpipe.fragments.detail.VideoDetailFragment$4@4feadd9
    at android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0(LoadedApk.java:1401)
    at android.app.-$$Lambda$LoadedApk$ReceiverDispatcher$Args$_BumDX2UKsnxLVrE6UJsJZkotuA.run(Unknown Source:2)
    at android.os.Handler.handleCallback(Handler.java:873)
    at android.os.Handler.dispatchMessage(Handler.java:99)
    at android.os.Looper.loop(Looper.java:193)
    at android.app.ActivityThread.main(ActivityThread.java:6718)
    at java.lang.reflect.Method.invoke(Native Method)
    at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:491)
    at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:858)
Caused by: java.lang.IllegalStateException: Not allowed to start service Intent { cmp=org.schabi.newpipe/.player.MainPlayer }: app is in background uid UidRecord{1b3bf85 u0a590 CAC  bg:+2m34s765ms idle procs:1 seq(0,0,0)}
    at android.app.ContextImpl.startServiceCommon(ContextImpl.java:1577)
    at android.app.ContextImpl.startService(ContextImpl.java:1532)
    at android.content.ContextWrapper.startService(ContextWrapper.java:664)
    at org.schabi.newpipe.player.helper.PlayerHolder.startService(PlayerHolder.java:59)
    at org.schabi.newpipe.fragments.detail.VideoDetailFragment$4.onReceive(VideoDetailFragment.java:1343)
    at android.app.LoadedApk$ReceiverDispatcher$Args.lambda$getRunnable$0(LoadedApk.java:1391)
    ... 8 more

---

Device info

• Android version/Custom ROM version: Android 9
• Device model: Pocophone F1

[Stypox]

I don't think we should put any effort into fixing this. Usually users do not have multiple NewPipes

[opusforlife2]

Also, this conflict doesn't happen between two release builds. At least one of them has to be a debug build.

@Stypox But testers do have multiple Newpipes. And testing often involves comparing differences between them, especially when videos are playing. Testing would become absolute hell if I had to test one build, close it, then open the other and then test it, back and forth, back and forth.

So to me this isn't low priority at all. Medium priority at least. :P

[opusforlife2]

Or developers would have to ensure they're uploading release builds.

[opusforlife2]

A debug build doesn't cause problems when used alongside a pre-0.20.0 debug build. So there is definitely something in the new version. My guess is the notification code, since that also seems to cause other problems as users have noted.

[Sunshinesol]

Exception

• __User Action:__ requested stream
• __Request:__ https://www.youtube.com/watch?v=28P95Gy5ZAY
• __Content Country:__ US
• __Content Language:__ en-US
• __App Language:__ en_US
• __Service:__ YouTube
• __Version:__ 0.20.1
• __OS:__ Linux Android 5.1.1 - 22
  
  Crash log

org.schabi.newpipe.extractor.exceptions.ParsingException: YouTube did not provide player config even after three attempts
    at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.onFetchPage(YoutubeStreamExtractor.java:664)
    at org.schabi.newpipe.extractor.Extractor.fetchPage(Extractor.java:56)
    at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:68)
    at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:64)
    at org.schabi.newpipe.util.ExtractorHelper.lambda$getStreamInfo$3(ExtractorHelper.java:116)
    at org.schabi.newpipe.util.-$$Lambda$ExtractorHelper$5fJcha6Sq5APJBLdG6osaJby-mc.call(lambda)
    at io.reactivex.internal.operators.single.SingleFromCallable.subscribeActual(SingleFromCallable.java:44)
    at io.reactivex.Single.subscribe(Single.java:3666)
    at io.reactivex.internal.operators.single.SingleDoOnSuccess.subscribeActual(SingleDoOnSuccess.java:35)
    at io.reactivex.Single.subscribe(Single.java:3666)
    at io.reactivex.internal.operators.maybe.MaybeFromSingle.subscribeActual(MaybeFromSingle.java:41)
    at io.reactivex.Maybe.subscribe(Maybe.java:4290)
    at io.reactivex.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.drain(MaybeConcatArray.java:153)
    at io.reactivex.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.request(MaybeConcatArray.java:78)
    at io.reactivex.internal.operators.flowable.FlowableElementAtMaybe$ElementAtSubscriber.onSubscribe(FlowableElementAtMaybe.java:66)
    at io.reactivex.internal.operators.maybe.MaybeConcatArray.subscribeActual(MaybeConcatArray.java:42)
    at io.reactivex.Flowable.subscribe(Flowable.java:14935)
    at io.reactivex.internal.operators.flowable.FlowableElementAtMaybe.subscribeActual(FlowableElementAtMaybe.java:36)
    at io.reactivex.Maybe.subscribe(Maybe.java:4290)
    at io.reactivex.internal.operators.maybe.MaybeToSingle.subscribeActual(MaybeToSingle.java:46)
    at io.reactivex.Single.subscribe(Single.java:3666)
    at io.reactivex.internal.operators.single.SingleSubscribeOn$SubscribeOnObserver.run(SingleSubscribeOn.java:89)
    at io.reactivex.Scheduler$DisposeTask.run(Scheduler.java:578)
    at io.reactivex.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:66)
    at io.reactivex.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:57)
    at java.util.concurrent.FutureTask.run(FutureTask.java:237)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:152)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:265)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
    at java.lang.Thread.run(Thread.java:818)

---

....help?

[B0pol]

I don't think we should put any effort into fixing this. Usually users do not have multiple NewPipes

When they test, they do. When they install a debug apk which fixes newpipe (right now), they do.

[XiangRongLin]

I have a similar problem too. when running multiple debug builds and having their notification present. if you close one, then start playing on the other, the closed one appears again.

I remember seeing in the code somewhere a hardcoded ID for broadcast (or something similar) towards the notifications. With multiple apps they would all them receive it.

Edit: https://github.com/TeamNewPipe/NewPipe/blob/dfd6424d9ceb8972ab727e8332b2aaea672f3116/app/src/main/java/org/schabi/newpipe/player/NotificationUtil.java#L46

[avently]

All broadcasts should use package name instead of hardcoded strings

[B0pol]

Not to mention the related bugs: if you pause one NewPipe, the other one will resume. If you delete the notification from one NewPipe, the other one will delete notification too