Closed ghost closed 2 years ago
@Ammako Does apk in #6841 solve the bug for you?
No, and I don't use queue anyway.
In fact I got the buffering to occur after only two videos in the RC, whereas on 0.21.8 I had to watch 15-20 before it finally occured. That might have just been random chance though.
Same thing happens for me.
The Kodi YouTube plug-in and youtube-dl seem to have a similar problem.
https://github.com/anxdpanic/plugin.video.youtube/issues/163
https://github.com/ytdl-org/youtube-dl/issues/29326
tl;dr: YT sends a .js file with some JavaScript for the browser to execute and passes a value to it. Browser must execute JavaScript which calculates the new value and returns it. If the value is wrong or not returned then the stream is eventually throttled to about 50KB/s. Some metadata is involved as you can clear the Kodi YouTube plug-in's data cache and play the same video again and that will make throttling go away for a while.
Proposed solutions in the linked issues are cancelling the download and restarting it, spoofing an Android device (devices which present themselves as Android don't seem to have this problem), creating a regex which picks out the values to be returned from JavaScript file (but that may be easily defeated by YouTube), or running a full JavaScript interpreter.
For me its very inconsistant, a 1 hour video could run fine then the next video i pick which could be around 20 minutes could slow to a halt.
I'm also experiencing the same issue on the latest version 0.21.11 with good connection. It's more frustrating because the majority of time, even clearing cache doesn't fix the issue.
Yeah, in recent times it's gotten a lot worse. Every time without fail, and half of the time clearing cache + restart app doesn't help.
On the plus side, I guess it's a lot easier to reproduce now, if ever needed.
Here is the pull request for the change which fixed (for now) the issue in yt-dlp (youtube-dl fork). They took the "spoofing an Android device" approach:
https://github.com/yt-dlp/yt-dlp/pull/492
Click through to issue 319 at the bottom of the linked page about the age-gate bypass to see some more info about what parameters they pass to YT.
Would this apply to NewPipe (extractor) though? Given that it's already being ran from an Android device. Or does NewPipe spoof not being an Android device?
I guess NewPipe might be sending parameters in a slightly different way which means YT realises it's not the real YT Android client.
This is why it doesn't happen in Vanced, it's the real YT client with adverts stripped out.
An observation: switching video resolution to 480p, no issues, ever. 720p and above though, basically unwatchable.
I wonder if they might be doing something similar to Netflix, where 480p and lower are unrestricted, but HD resolutions require stricter authenticatiom checks?
I switched the default resolution in the settings, so videos always load at 480p directly. Reloading never fixes it for me unfortunately.
Switching to Vanced for playback. NewPipe is completely unusable right now. Lots of infinite buffering, stream background playback is absolutely a nightmare and usually ends with the playback crashing & the buffer being reloaded aka past 20secs over and over again.
I understand that this is an app developed by people in their free time without any or enough donations, but this not acceptable developement. This issue has been around for too long and if vanced can get around it, surely newpipe can too.
Hmmm... no, this development is perfectly acceptable 👍
We're talking about a bug that affect some people, indeed, but it's not a bug that affects everyone either (otherwise the repositories would be flooded with similar issues).
So it's quite conceivable that developers don't focus only on this problem. Especially since this problem is not systematic and not easily trackable.
If Vanced works, that's cool. That means that "maybe" there is a solution that "maybe" can be implemented in the future.
Let's give them time and wait patiently, or use another program in the meantime (if need), but let them do as they please. 😉
Nobody cares if you're switching from one free app to another. The world doesn't revolve around you.
Comparing Vanced to NewPipe is apples to oranges.
Either way, I'm updating the issue title, because I think the cached metadata thing may have been a red herring. Please refrain from posting comments unless you actually have something to contribute.
Nobody cares if you're switching from one free app to another. The world doesn't revolve around you.
Comparing Vanced to NewPipe is apples to oranges.
Either way, I'm updating the issue title, because I think the cached metadata thing may have been a red herring. Please refrain from posting comments unless you actually have something to contribute.
Pompous arrogant sh- head. Go outside and touch some gras.
If you would actually have more than one neuron or axon up there, you'd have seen that I already differentiated pipe and vanced from each other, contributed by stating the issue + versioning + preview of gif but who cares if you can sound like the really cool kids these days right...
How arrogant can you be to then tell me to screw off unless I contribute. Go eat s-, I will delete all my comments except this one, because you are not even worth a single ounce of support.
Good luck finding someone to help you with new pipe and your issues above your shoulders, the latter being definitely the greater one...
We're talking about a bug that affect some people.
I have it too:
Xiaomi Mi 9T pro Android 10 (lineageos without google)
Do you have problems with 480p or lower? I'm interested in seeing if this issue only affects HD and higher resolutions.
Sometimes switching to a different res fixes it. See cases describes above. Usually non-720p or webp can solve the problem, but not always.
Are there any plans on switching to yt-dlp? I noticed it was mentioned earlier. I don't know about android, but on Linux desktop yt-dlp has a lot better speeds then yt-dl for the reasons mentioned above.
I have also noticed that switch between cellular and wifi fixes buffering for a minute or two.
@minecraftchest1 Newpipe doesn't use youtube-dl. It uses the Newpipe Extractor, which has been written from scratch.
We're talking about a bug that affect some people, indeed, but it's not a bug that affects everyone either (otherwise the repositories would be flooded with similar issues). So it's quite conceivable that developers don't focus only on this problem. Especially since this problem is not systematic and not easily trackable.
I would like to chime in that I am also experiencing the issue. NewPipe is basically unusable for me for videos. I am also experiencing this issue in youtube-dl, and they showed up around the same time, so this may be IP-based.
YT sends a .js file with some JavaScript for the browser to execute and passes a value to it. Browser must execute JavaScript which calculates the new value and returns it. If the value is wrong or not returned then the stream is eventually throttled to about 50KB/s
This sounds to me like YouTube is specifically implementing a new system for suppressing traffic from 3rd-party services like NewPipe and youtube-dl
. It seems to me prudent, therefore, to implement a fix which specifically targets their mechanism for implementing this check -- by executing the relevant javascript or parsing it and performing the intended operation just as a web-browser would.
I have some coding experience, and would like to help with this issue, but I'm not familiar with the internal workings of NewPipe, Could people familiar with the relevant moving parts provide comments here which would provide documentation to people with development experience who are users and not yet contributors to gain the background knowledge necessary to contribute? (looked into this and it's over my head, sorry)youtube-dl
, or this javascript check which youtube has implemented.
I was having this issue (constant buffering) and thought it might be resolution based, so it was showing 720, so I tapped it, and selected 480, and the app crashed. It came up with a Guru Mediation, as below: 1 Phone is OnePlus 5T. 2 I was watching blind auditions voice worldwide 3 I never gave it on auto queue 4 I was selecting the next to watch by opening the channel of each, and seeing if there was sufficient material to warrant subscribing. 5 In other words there never was a playlist (maybe its buffering based on not finding a playlist?)
java.lang.IllegalArgumentException: Play Queue has not been initialized.
at org.schabi.newpipe.player.playback.MediaSourceManager.<init>(MediaSourceManager.java:141)
at org.schabi.newpipe.player.playback.MediaSourceManager.<init>(MediaSourceManager.java:130)
at org.schabi.newpipe.player.Player.reloadPlayQueueManager(Player.java:884)
at org.schabi.newpipe.player.Player.onMenuItemClick(Player.java:3495)
at android.widget.PopupMenu$1.onMenuItemSelected(PopupMenu.java:108)
at com.android.internal.view.menu.MenuBuilder.dispatchMenuItemSelected(MenuBuilder.java:787)
at com.android.internal.view.menu.MenuItemImpl.invoke(MenuItemImpl.java:151)
at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:934)
at com.android.internal.view.menu.MenuBuilder.performItemAction(MenuBuilder.java:924)
at com.android.internal.view.menu.MenuPopup.onItemClick(MenuPopup.java:128)
at android.widget.AdapterView.performItemClick(AdapterView.java:330)
at android.widget.AbsListView.performItemClick(AbsListView.java:1257)
at android.widget.AbsListView$PerformClick.run(AbsListView.java:3265)
at android.os.Handler.handleCallback(Handler.java:883)
at android.os.Handler.dispatchMessage(Handler.java:100)
at android.os.Looper.loop(Looper.java:214)
at android.app.ActivityThread.main(ActivityThread.java:7697)
at java.lang.reflect.Method.invoke(Native Method)
at com.android.internal.os.RuntimeInit$MethodAndArgsCaller.run(RuntimeInit.java:516)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:950)
Solution for Kodi's YT Plugin seems to be the following:
https://github.com/ytdl-org/youtube-dl/issues/29326#issuecomment-938337251
https://github.com/anxdpanic/plugin.video.youtube/issues/163#issuecomment-894859991
https://github.com/anxdpanic/plugin.video.youtube/issues/163#issuecomment-939156545
Newpipe running on Firestick 4K, crash
uierror ACRA report version 0.21.10 OS version Linux NHG47K 7.1.2-25
"Failed to allocate a 4355412 byte allocation with 3617176 free bytes avail at dalvik.system.VMRuntime.newNonMovableArray(Native Method)
Have watched maybe 40 blind auditions, and subscribing to maybe 13 channels. I don't think it's releasing memory.
@what-aboot That's a completely unrelated error. Please open a new issue for it, after checking for duplicates.
Could you please test the APK of #6537 which makes the app use the streaming URLs of the WEB
YouTube client first (with the n
param unthrottled (it is the case for these URLs since version 0.21.8 of the app) and with some other params of official clients too) and see if you have buffering issues with this APK? Thank you in advance.
Direct link of the APK: https://github.com/TeamNewPipe/NewPipe/suites/4224687319/artifacts/109290035
I switched back to 720p and I can't seem to get the buffering to happen again right now, on 0.21.13, so I'm not sure if I would be able to tell a difference. I got a different phone nowadays, and it might be doing things differently in a way where this problem doesn't happen.
I'm here to report I am also experiencing this issue. Ver. 0.21.13
I'm here to report I am also experiencing this issue. Ver. 0.21.13
@quickdude111 There is no point in that. You can help us more if you test the APK as asked two comments above yours.
@opusforlife2 @TiA4f8R I have now tested this apk and it shows no change in the issue. it's as if i'm being throttled nonstop.
Hi,
A small observation on my part. This may not be a direct problem with buffering, but the slow movement between items / channels. Sometimes the effect is that it takes a few seconds for the channel to load.
This problem has been around for a very long time for at least several versions. Recently, I looked closely at it and the conclusions that came out of it...
The problem is due to the very strange behavior of the dns cache. If the device or server has an old cache for the domain www.youtube.com or no cache at all, NP lags. If I dig www.youtube.com earlier and repeat it every minute, then the dns cache is current and fresh and, surprisingly, NP does not lag. This looks like a strange problem with the short TTL for the domain and allocating the nearest CDN via dns.
For me, www.youtube.com points to: ;www.youtube.com. IN A
;; ANSWER SECTION: www.youtube.com. 21s IN CNAME youtube-ui.l.google.com. youtube-ui.l.google.com. 21s IN A 216.58.209.14 youtube-ui.l.google.com. 21s IN A 216.58.215.110 youtube-ui.l.google.com. 21s IN A 216.58.215.78 youtube-ui.l.google.com. 21s IN A 172.217.16.46 youtube-ui.l.google.com. 21s IN A 172.217.16.14 youtube-ui.l.google.com. 21s IN A 172.217.20.206 youtube-ui.l.google.com. 21s IN A 172.217.20.174 youtube-ui.l.google.com. 21s IN A 142.250.203.142 youtube-ui.l.google.com. 21s IN A 142.250.186.206 youtube-ui.l.google.com. 21s IN A 142.250.75.14 youtube-ui.l.google.com. 21s IN A 216.58.208.206 youtube-ui.l.google.com. 21s IN A 142.250.203.206
;youtube-ui.l.google.com. IN A
;; ANSWER SECTION: youtube-ui.l.google.com. 4m16s IN A 172.217.16.46 youtube-ui.l.google.com. 4m16s IN A 172.217.16.14 youtube-ui.l.google.com. 4m16s IN A 172.217.20.206 youtube-ui.l.google.com. 4m16s IN A 172.217.20.174 youtube-ui.l.google.com. 4m16s IN A 142.250.203.142 youtube-ui.l.google.com. 4m16s IN A 142.250.186.206 youtube-ui.l.google.com. 4m16s IN A 142.250.75.14 youtube-ui.l.google.com. 4m16s IN A 216.58.208.206 youtube-ui.l.google.com. 4m16s IN A 142.250.203.206 youtube-ui.l.google.com. 4m16s IN A 216.58.209.14 youtube-ui.l.google.com. 4m16s IN A 216.58.215.110 youtube-ui.l.google.com. 4m16s IN A 216.58.215.78
I also made sure that youtube-ui.l.google.com is not blocked anywhere. If someone uses pihole or their own dns, they should note that the first query for the domain is executed and cached, but the client does not receive it anyway and only the second query proceeds normally. You can also see that the cache for www.youtube.com is very short.
Setting dig www.youtube.com in the background to run every minute solves the lag problem... as long as the OS or dns server has a fresh cache for the domain all the time.
Can someone check if similar behavior is taking place? If you do not have a dns server then perform domain polling directly on the NP device. In my case, such continuous querying of the domain brought a surprising improvement in the operation of NP.
Perhaps devs could implement a small piece of NP code that will notoriously poll dns servers every minute for www.youtube.com?
A separate issue is the behavior of google / youtube.com on the desktop and firefox... When I go to the website, FF tries to make UDP 443 connections to IP addresses that dns returns for youtube-ui.l.google.com regardless of the system dns 53. It looks that google generated additional connections using its JS script to its infrastructure omitting the normal dns...
I speculate that this may also affect NP.
:/
@zeropi2021 This is not related to this issue because here we are talking about video and audio streaming which is served with playback hosts from googlevideo.com
servers (like r5--sn--4g5edndz.googlevideo.com
).
However, the player data is fetched indeed from www.youtube.com
, and also from youtubei.googleapis.com
.
This is not related to this issue because here we are talking about video and audio streaming which is served with playback hosts from
googlevideo.com
servers (liker5--sn--4g5edndz.googlevideo.com
).However, the player data is fetched indeed from
www.youtube.com
, and also fromyoutubei.googleapis.com
.
@TiA4f8R
As I mentioned before... So I thought it had nothing to do with video buffering. But I thought that I would share my five cents, maybe it will be useful to someone as a tip or not... I remember once people complained not only about video buffering but also NP responsiveness but maybe newer versions improved it for others. :)
Yes, the video stream is pulled from these other domains, but they also have a short TTL. Are you saying there's absolutely no correlation there? There is no logic, yes, I do not see how it would affect video buffering. But I have evidently seen an improvement in overall NP responsiveness, although it has no effect on video buffering, of course. Although personally on 0.21.13 I am not experiencing the buffering that was previously on older versions. Although I feel sorry for those who still have this problem! :(
If my posts are totally offtopic then move them elsewhere if necessary. :)
The problem in the issue description also happens from time to time on my device, however only when I start watching a video. Usually skipping the first 10s solves the problem 😄
@zeropi2021
The problem is due to the very strange behavior of the dns cache. If the device or server has an old cache for the domain www.youtube.com or no cache at all, NP lags.
Please open a new issue.
Please open a new issue.
@litetex
I am not sure if it makes sense... Maybe I am the only one who had this problem and at the moment I am dealing with this problem with the MacGyver method so it does not make sense to do spam if others do not mention this problem at the moment. :)
*report below from trying to watch video at 360p as normal streaming within app.
I have been having this issue at least once or twice daily for a while now. I doubt this will be helpful but it seems like it is video specific throttling of certain videos. For instance earlier today I tried downloading audio opus 50 of a specific video and my download speeds were ridiculously slow. Like 15-50 Kb/s. I Tried queuing up concurrently a couple other opus 50 audio downloads I had in the que and they proceeded to download at normal speeds while the first one just trudged along like a snail. I paused it, tried resumeing again same. I tried canceling it and starting over and the same story. Tried watching the video via streaming the normal way and constant buffering. Try watching it at different resolutions (normal is 360p for me) same buffering issues. Tryed watching different video it works as normal. Decided I would watch it later in the day. 8 hours later try watching it via streaming same buffering issues for that video. Try downloading the opus 50 again same turtles pace. Try background streaming same non stop pauses in audio. Watch a different video or download a different audio opus 50 it works perfectly. Will try to pay attention from now on if creator specific
Crash log 1
org.schabi.newpipe.extractor.exceptions.ParsingException: Could not get like count
at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getLikeCount(YoutubeStreamExtractor.java:359)
at org.schabi.newpipe.extractor.stream.StreamInfo.extractOptionalData(StreamInfo.java:281)
at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:73)
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.ExtractorHelper.$r8$lambda$YTHJjScxCJNO1LTCqs3IKy35iyY(Unknown Source:0)
at org.schabi.newpipe.util.ExtractorHelper$$ExternalSyntheticLambda6.call(Unknown Source:4)
at io.reactivex.rxjava3.internal.operators.single.SingleFromCallable.subscribeActual(SingleFromCallable.java:43)
at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813)
at io.reactivex.rxjava3.internal.operators.single.SingleDoOnSuccess.subscribeActual(SingleDoOnSuccess.java:35)
at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeFromSingle.subscribeActual(MaybeFromSingle.java:41)
at io.reactivex.rxjava3.core.Maybe.subscribe(Maybe.java:5330)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.drain(MaybeConcatArray.java:153)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.request(MaybeConcatArray.java:78)
at io.reactivex.rxjava3.internal.operators.flowable.FlowableElementAtMaybe$ElementAtSubscriber.onSubscribe(FlowableElementAtMaybe.java:66)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray.subscribeActual(MaybeConcatArray.java:42)
at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15753)
at io.reactivex.rxjava3.internal.operators.flowable.FlowableElementAtMaybe.subscribeActual(FlowableElementAtMaybe.java:36)
at io.reactivex.rxjava3.core.Maybe.subscribe(Maybe.java:5330)
at io.reactivex.rxjava3.internal.operators.maybe.MaybeToSingle.subscribeActual(MaybeToSingle.java:46)
at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813)
at io.reactivex.rxjava3.internal.operators.single.SingleSubscribeOn$SubscribeOnObserver.run(SingleSubscribeOn.java:89)
at io.reactivex.rxjava3.core.Scheduler$DisposeTask.run(Scheduler.java:614)
at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:65)
at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:56)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
at java.lang.Thread.run(Thread.java:919)
Caused by: org.schabi.newpipe.extractor.exceptions.ParsingException: Ratings are enabled even though the like button is missing
at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getLikeCount(YoutubeStreamExtractor.java:348)
... 30 more
Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String[] java.lang.String.split(java.lang.String)' on a null object reference
at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getLikeCount(YoutubeStreamExtractor.java:344)
... 30 more
``` org.schabi.newpipe.extractor.exceptions.ParsingException: Could not get dislike count at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getDislikeCount(YoutubeStreamExtractor.java:388) at org.schabi.newpipe.extractor.stream.StreamInfo.extractOptionalData(StreamInfo.java:286) at org.schabi.newpipe.extractor.stream.StreamInfo.getInfo(StreamInfo.java:73) 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.ExtractorHelper.$r8$lambda$YTHJjScxCJNO1LTCqs3IKy35iyY(Unknown Source:0) at org.schabi.newpipe.util.ExtractorHelper$$ExternalSyntheticLambda6.call(Unknown Source:4) at io.reactivex.rxjava3.internal.operators.single.SingleFromCallable.subscribeActual(SingleFromCallable.java:43) at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813) at io.reactivex.rxjava3.internal.operators.single.SingleDoOnSuccess.subscribeActual(SingleDoOnSuccess.java:35) at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813) at io.reactivex.rxjava3.internal.operators.maybe.MaybeFromSingle.subscribeActual(MaybeFromSingle.java:41) at io.reactivex.rxjava3.core.Maybe.subscribe(Maybe.java:5330) at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.drain(MaybeConcatArray.java:153) at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray$ConcatMaybeObserver.request(MaybeConcatArray.java:78) at io.reactivex.rxjava3.internal.operators.flowable.FlowableElementAtMaybe$ElementAtSubscriber.onSubscribe(FlowableElementAtMaybe.java:66) at io.reactivex.rxjava3.internal.operators.maybe.MaybeConcatArray.subscribeActual(MaybeConcatArray.java:42) at io.reactivex.rxjava3.core.Flowable.subscribe(Flowable.java:15753) at io.reactivex.rxjava3.internal.operators.flowable.FlowableElementAtMaybe.subscribeActual(FlowableElementAtMaybe.java:36) at io.reactivex.rxjava3.core.Maybe.subscribe(Maybe.java:5330) at io.reactivex.rxjava3.internal.operators.maybe.MaybeToSingle.subscribeActual(MaybeToSingle.java:46) at io.reactivex.rxjava3.core.Single.subscribe(Single.java:4813) at io.reactivex.rxjava3.internal.operators.single.SingleSubscribeOn$SubscribeOnObserver.run(SingleSubscribeOn.java:89) at io.reactivex.rxjava3.core.Scheduler$DisposeTask.run(Scheduler.java:614) at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:65) at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:56) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:301) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641) at java.lang.Thread.run(Thread.java:919) Caused by: org.schabi.newpipe.extractor.exceptions.ParsingException: Ratings are enabled even though the dislike button is missing at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getDislikeCount(YoutubeStreamExtractor.java:377) ... 30 more Caused by: java.lang.NullPointerException: Attempt to invoke virtual method 'java.lang.String[] java.lang.String.split(java.lang.String)' on a null object reference at org.schabi.newpipe.extractor.services.youtube.extractors.YoutubeStreamExtractor.getDislikeCount(YoutubeStreamExtractor.java:373) ... 30 more ```
I see both those exceptions are metadata ( like/dislike count ), and in opening that requested link I see YT has it "disabled". Perhaps only except on being unable to get the strea m, with all others ignored if inaccessible after a brief timeout?
My eagerness is to watch content, not see like / dislike counters. To realise that all that f@rt1ng about was because it couldn't access a counter would be laughable if it wasn't so tragic.
@what-aboot @dagfinnr1 → https://github.com/TeamNewPipe/NewPipe/issues/7405
APK of #6537 is 5-10 times slower for me. 0.21.13 is currently refusing to load 1080p60 videos, although I have a speed on download with it of about 1-2mbytes/s. Also, constantly flashing "something went wrong", although idk if it is related.
After installing VancedYT and VancedMicroG NewPipe actually started buffering faster. Idk if it's a coincidence.
After installing VancedYT and VancedMicroG NewPipe actually started buffering faster. Idk if it's a coincidence.
Installing vancedMicroG alone worked for me. Thank you for the tip. https://github.com/YTVanced/VancedMicroG
After installing VancedYT and VancedMicroG NewPipe actually started buffering faster. Idk if it's a coincidence.
Installing vancedMicroG alone worked for me. Thank you for the tip. https://github.com/YTVanced/VancedMicroG
And what exactly does MicroG have to do with the newpipe?
As far as I know NewPipe is a completely standalone application - so nothing else (besides Android) should be required to run it. So it's likely a coincidence.
Resetting cached metadata (under "History and cache>wipe cached metadata" might help.
Perhaps there is something that VancedYT and VancedMicroG are doing that convinces the YT server that it's talking to the official YT app, so the server doesn't throttle the client's IP?
Perhaps there is something that VancedYT and VancedMicroG are doing that convinces the YT server that it's talking to the official YT app, so the server doesn't throttle the client's IP?
I have big doubts whether youtube performs this type of analysis per IP and not a per cative tcp session... If they were doing something per IP, such behavior on a lot of GSM and VPN operators and any NAT where you have a lot of people per IP would be quickly noticed.
Besides, I don't use "VancedYT and VancedMicroG" and in my case the newpipe doesn't show buffering for a long time. I would say that with version 0.21.13 the problem stopped / decreased. I do not see buffering at the moment also in 0.21.14 RC2
The only thing I notice sometimes is the allocation of a distant CDN (1e100.net) to the source and the fact that there are CDNs much closer. Teretically this could cause buffering at times.
dirkf fixed this issue for youtube-dl (written in python) here, this might work for NewPipe when converted to Java. Fix: https://raw.githubusercontent.com/ytdl-org/youtube-dl/d69983a8756fa75e16606bcd1b2ba50ec115ed16/youtube_dl/extractor/youtube.py Context: https://github.com/ytdl-org/youtube-dl/issues/29326#issuecomment-977026306 PR: https://github.com/ytdl-org/youtube-dl/pull/30184
The issue returned for me, again constant buffering. Idk what is the reason, but the app is unusable this way. And I quite like it. Maybe I can help sharing some logs or smth? I really want it to work, and I don't know nearly enough to understand what is the reason this happens. I would think there would be a way to force the app to buffer more, or to make a setting for minimal buffering time, or smth..but these things are probably outside of the app's control, I'm guessing YT servers responsible for these things. Anyhow, hope this gets resolved. Again. And that I can return to using NewPipe.
The issue returned for me, again constant buffering. Idk what is the reason, but the app is unusable this way. And I quite like it. Maybe I can help sharing some logs or smth? I really want it to work, and I don't know nearly enough to understand what is the reason this happens. I would think there would be a way to force the app to buffer more, or to make a setting for minimal buffering time, or smth..but these things are probably outside of the app's control, I'm guessing YT servers responsible for these things. Anyhow, hope this gets resolved. Again. And that I can return to using NewPipe.
Yeah...some videos load very slowly despite having a connection speed of 15MB/s. IMHO...buffering cache need to be resized. Maybe now it's too conservative.
The Buffering problem is still not fixed with the new version :(
As far as I know NewPipe is a completely standalone application - so nothing else (besides Android) should be required to run it. So it's likely a coincidence.
Resetting cached metadata (under "History and cache>wipe cached metadata" might help.
It didn't fix anything for me
Checklist
Steps to reproduce the bug
I use WebM, if that matters.
Actual behavior
Eventually, seemingly at random, a video will decide it wants to endlessly buffer on/off, making it unwatchable.
When this happens, I can see that download speed consistently stays at around 60 KB/s. Closing out of the video, clearing cached metadata, then returning to that same video makes it work as normal again, varying between 100 B/s to 1-2 MB/s as you would expect.
Expected behavior
For one, the app is supposed to buffer at least 25 seconds ahead before playback resumes, as per https://github.com/TeamNewPipe/NewPipe/issues/5516#issuecomment-901382592. Simply enforcing the 25 second minimum probably wouldn't fix the underlying issue, though.
Screenshots/Screen recordings
https://user-images.githubusercontent.com/43770697/130306929-8e92318c-5629-47ca-99ef-df0826f8ccae.mp4
Logs
Cleaned up to remove screen recorder spam, from the moment I enabled the recorder to the end of the recording. I hope that's enough?
Click to reveal
Device info