TeamNewPipe / NewPipe

A libre lightweight streaming front-end for Android.
https://newpipe.net
GNU General Public License v3.0
31.61k stars 3.08k forks source link

Buffering video unrelated to connection #6510

Closed n0rder closed 3 years ago

n0rder commented 3 years ago

Screen recording

As you can see in the screen record videos randomly buffer when in video mode, however in background mode the audio plays fine.

This issue is limited to newpipe and other video apps work fine.

Samsung galaxy s10+ android 11

Reinstalling newpipe doesn't work Changing Internet connection doesn't work

matheusAMDS commented 3 years ago

I can't visualize the link you shared, but i'm having problems with my videos infinitely loading. Maybe its something related?

LauriKat commented 3 years ago

I am having same issue as OP. Thought new version would solve it had something buffering related improvements but I still have this problem

Redmi Note 8 pro Android 10

botistreamer commented 3 years ago

I am also having same issue in 0.21.5 on some videos randomly. Poco X3 - Android 11

djuarezr commented 3 years ago

Same here, even though with version 0.21.5 the problem has been mitigated a lot. If logs are needed just let me know.

Xiaomi Mi 9T - Miui 12.0.5 - Android 10

Redirion commented 3 years ago

please try this apk: https://github.com/TeamNewPipe/NewPipeExtractor/pull/604

if the problem also happens with that apk, please collect the adb logcat logs from the issue

triallax commented 3 years ago

For all those facing this issue, using external players will probably not have this issue.

djuarezr commented 3 years ago

It is the first time I try to get a logcat so I do not know whether it is what you need, but I got it. The logcat is from TeamNewPipe/NewPipeExtractor#604. Video starts at line 12, and after 30 seconds it starts the continuous buffering.

Hope this helps.

NewPipe_YoutubeI_Api.log

Redirion commented 3 years ago

thanks. A quick glance shows these log lines demand further inspection as they might be the cause (but not the root cause) of the issue:

AudioTrack: getTimestamp_l(417): retrograde timestamp time corrected AudioTrack: getTimestamp_l(417): device stall time corrected using current time

Redirion commented 3 years ago

@djuarezr could you try if the issue also happens with Media Tunneling disabled? You find the option to disable that in the debug options.

djuarezr commented 3 years ago

First I should have mentioned before that the log that I posted before is from a video at 1.5x speed. So far it also happens when tunneling is disabled. But I could not replicate the issue with the same video anymore. Thus, to be more precise, here is a more fair comparison I made. Every log is from a clean app, 1080p webM video, and the smartphone at the exact same distance to WiFi:

Hope all these logs could help to decrypt the issue.

lordkitsuna commented 3 years ago

ill throw my hat in. i am having issues with newpipe buffering super slowly initially on a 1Gbps connection (530Mbps verified as possible on wifi locally with iperf3) video at any quality stalls for upwards of 30 seconds, after that they play fine unless i seek out far then it happens again. fresh install of lineageos, tons of free space, no gapps or anything so cpu is pretty quiet.

happy to provide any info i can just let me know what you need

Taratect commented 3 years ago

I used to have this problem till the version 0.21.5 came out. So far there hasn't been any buffering. Hope if updating helps n I'll update if I face buffering while using the latest version atm.

Also I'd like to let I know as @djuarezr pointed, I also watch my vids by increasing playback speed of this is somehow related.

Edit: Now I'm suffering from buffering regardless of good internet connection

stoneubi commented 3 years ago

Same here. Since two or three versions this buffering problem occurs. Before that, everything worked perfectly. Latest version hasn't fixed this. Realme 6. Hope this issue will be fixed as for now newpipe cannot play every video.

nikhilCad commented 3 years ago

I do not know whether it is related to this issue or not but loading large videos like 10hr+ take a very long time as compared to the normal 10-15 minute videos.

TheGrigoryans commented 3 years ago

exactly, same problem 2 smartphones, redmi 8note, redmi 9t, version 0.21.5

dankxylese commented 3 years ago

I'll add some of my experience with this bug.

Killing the app and restarting it fixes the problem for me (I have long press back bind to kill apps).

It will usually hover over 250-280KB/s for me when it's stuck in that bugged state. After killing and restarting the app, going to history and playing the same video, it instantly peeks to 4-6MB/s and nicely loads the video.

My guess would be that it might be YouTube figuring out the client is "not official" and throttling the connection. Or maybe there are slow servers that NewPipe is connecting to, since just killing the app, no cache clear or anything fixes the issue for me.

Android 10 AICP (AOSP based). Rooted + Magisk and Xposed modules loaded. OnePlus 5T.

I'll make sure to grab a logcat when it happens next time for me, so I can try and capture the before and after killing the app. Maybe it'll help lead to the issue.

Edit: also I'm still on 0.21.4 and experiencing this so definitely wasn't from 0.21.5 alone

dankxylese commented 3 years ago

First I should have mentioned before that the log that I posted before is from a video at 1.5x speed. So far it also happens when tunneling is disabled. But I could not replicate the issue with the same video anymore. Thus, to be more precise, here is a more fair comparison I made. Every log is from a clean app, 1080p webM video, and the smartphone at the exact same distance to WiFi

In my case it enters this state one to 3-4 times a day, usually when Newpipe has been left in sleep for a while, or is a cold start (OnStart()/OnResume())?

Or could be YouTube breaking things again. Building an apk with the old exoplayer should rule that one out.

triallax commented 3 years ago

Or could be YouTube breaking things again. Building an apk with the old exoplayer should rule that one out.

That's precisely what #6524 is.

bzp99 commented 3 years ago

Same issue here, although I haven’t tried with v0.21.5 yet. Even on extremely low quality (say 360p), videos keep buffering every few seconds, making them impossible to watch. The network speed is fine, on another phone with the official app, there is no problem. Soft restarting or killing the app does not help. I am not sure, but I think this only happens with some videos.

opusforlife2 commented 3 years ago

Everyone facing the buffering issue, please test the APK in #6542. We wish to confirm that it fixes the problem.

djuarezr commented 3 years ago

I tried the APK in #6524 (could not get logs yet) and looks like the bug is gone. I had to play videos at greater than 2x speed to force some buffering. But I want other people to try the APK to compare.

Btw, I configured the APK to play videos at 1080p60 by default. Some videos I tried are not available at 1080p in youtube (just 720p or below), but newpipe allows me to play that video at 1080p60. Is there any rendering to upscale the resolution that could lead to this buffering issue?

ghost commented 3 years ago

Similar issue. Sometimes the bandwidth stays around 50-100KB/s 1080p and the video buffers, plays 0.5 seconds, then repeat. Cache wipe or app reset usually solves issue.

SeongGino commented 3 years ago

The #6542 artifact definitely seems to have alleviated the issue on my device that has been suspect to the hitching buffering on the last couple of versions.

Over the course of a 14 min 1080p60 video, it's only had a single microbuffer in the middle, a normal buffer pause towards the latter third at around the ten minute mark, and an elongated pause that I had to rewind -10s to alleviate; but in all cases, there is an actual buffer in vid playback that basically didn't exist before.

There does still seem to be some relative slowness in streaming compared to the YT app, but the biggest showstopper issue for me looks to be fixed here.

(Save for the build having a broken search, hopefully just a factor of the specific artifact pulled and not another full on regression)

EDIT: Unfortunately on the second video, the stop-and-go buffering seems to have reared itself a bit again. Using with WebM 720p60.

Donkey-Doug commented 3 years ago

Experiencing the same issues. Force closing the newpipe app and opening the same video again makes the video play normally. (Sometimes it is required to force close the app multiple times because it is not always fixed after 1 force close).

SeongGino commented 3 years ago

The issue only seems to have been diminished somewhat, but by no means 'fixed' by the test build. Looks to be the longer it's used from a fresh install, the less likely it's able to run ahead, and the more likely intermittent buffering happens.

litetex commented 3 years ago

Issue persists on my device even with #6542 However on most occasions deleting the cache and restarting the app helps.

litetex commented 3 years ago

Has someone tried to debug the exoplayer?

I added simpleExoPlayer.addAnalyticsListener(new EventLogger(trackSelector)); after https://github.com/TeamNewPipe/NewPipe/blob/484c852efd55eb2d0279c01d19529ea5b9d59f0a/app/src/main/java/org/schabi/newpipe/player/Player.java#L478 but so far I haven't had any buffering and didn't see any errors in the log.

djuarezr commented 3 years ago

I (finally) got a log with the buffering issue at 1x (1080p60 webM in audio and video). The apk I used is the one from #6542. Hope this can help.

ExoDowngrade2.log

EDIT: There are 3 videos I tried in the log: the first 2 are playing normal; the last one is the one with the buffering issue every half second approx. It starts at line 1158.

AudricV commented 3 years ago

The real issue is a YouTube change: see ytdl-org/youtube-dl#29326 and this comment for a solution. It requires an extractor change.

opusforlife2 commented 3 years ago

Ah. Makes sense. @Redirion As other users have reported, even with downgraded Exoplayer the buffering issue occurs sometimes, though it's much rarer (for me at least).

litetex commented 3 years ago

Could also catch the problem while sitting on the couch, attached my phone to the pc and got the logs: Getting every few hundred ms the following message:

2021-06-24 21:55:43.966 8646-8646/org.schabi.newpipe.debug.exp E/EventLogger: audioTrackUnderrun [eventTime=894.44, mediaPos=315.91, window=0, period=0, 44100, 250, 4597]

When tapping the play-button also this happens:

2021-06-24 21:55:30.231 8646-11618/org.schabi.newpipe.debug.exp E/AudioTrack: StreamType not music do not upload bigdata

More here: snippet.txt

ghost commented 3 years ago

For developer consider use exoplayer v1 as videi player for now

not all devices able to handle exoplayer v2 this one of cause why user on YouTube experience lagging blah blah blah

if newpipe use v2 consider it to downgrade v1

Redirion commented 3 years ago

if newpipe use v2 consider it to downgrade v1

sorry but that's nonsense

Dsw77 commented 3 years ago

Screen recording

As you can see in the screen record videos randomly buffer when in video mode, however in background mode the audio plays fine.

This issue is limited to newpipe and other video apps work fine.

Samsung galaxy s10+ android 11

Reinstalling newpipe doesn't work Changing Internet connection doesn't work

For me the buffering also happens with only background audio, randomly. Today it seemed to be resolved bij connecting over vpn, though on the same network.

Dennis

TacoTheDank commented 3 years ago

if newpipe use v2 consider it to downgrade v1

image

conkerts commented 3 years ago

I have also issues the last 2 weeks or so. I can't tell the precise date when it started. But what I observed was, that videos will stutter, but when I start playing them in background, for whatever reason they (/audio) work then. (And yeah, the last nnewpipe update improved it on most videos, but it still happens from time to time)

Another weird thing is that Android reported network activity around only 50 or 60KB/s, which is obviously not enough. I encountered that low speed on yt-dl, too. And yesterday I had stuttering even in firefox on my Laptop.

I suspect YT changed something on their side, too

ghost commented 3 years ago

I suspect YT changed something on their side, too

yt use exoplayer v2 that not all devices can handle that unfortunately

ghost commented 3 years ago

if newpipe use v2 consider it to downgrade v1

sorry but that's nonsense

hey it's real believe me i also experienced same issues

here my story: since yt v16.14.34 they use exoplayer v2 i already updated yt but well it's lagging like h*ll i tried to force codex VP9 actually it's worked but my battery are draining more faster and faster

come on bro I don't want force my devices due to battery hogging :(

Redirion commented 3 years ago

what is your device model @NSTAdventure ?

ghost commented 3 years ago

what is your device model @NSTAdventure ?

mine is realne 5i πŸ™

again as i said not all devices can handle v2 if yoy doesn't want to downgrade at least add option to revert exoplayer to v1 like yt vance version 15.43.32

litetex commented 3 years ago

@NSTAdventure

Some comments from my side to your statements:

not all devices able to handle exoplayer v2 this one of cause why user on YouTube experience lagging blah blah blah

β†’ https://exoplayer.dev/supported-devices.html Exoplayer supports most use cases as far back as Android 4.1; That covers 99,8% of all running android devices

For developer consider use exoplayer v1 as videi player for now ... if newpipe use v2 consider it to downgrade v1 ... yt use exoplayer v2 that not all devices can handle that unfortunately

Downgrading Exoplayer has nothing to do with this issue as stated above in https://github.com/TeamNewPipe/NewPipe/issues/6510#issuecomment-867789285. That's a completely different issue. Btw: Exoplayer 1 was last released in 2017.

since yt v16.14.34 they use exoplayer v2 i already updated yt but well it's lagging like h*ll i tried to force codex VP9 actually it's worked but my battery are draining more faster and faster

I presume you are talking about the YT app (or YT vanced)? NewPipe has no option to force VP9 as far as I know. Anyhow, this has nothing to do with NewPipe itself. You didn't state somewhere that you are even using the NewPipe app. β†’ However everything is completely off-topic; Maybe the comments should be marked as that (@TeamNewPipe) so others - that actually want to contribute something useful - don't get confused.

hey it's real believe me i also experienced same issues ... not all devices able to handle exoplayer v2 this one of cause why user on YouTube experience lagging blah blah blah ... come on bro I don't want force my devices due to battery hogging :(

It would also be great if you could express yourself in a nicer, more upscale way, that actually contributes something to this issue.

ghost commented 3 years ago

since what version of newpipe do you use exoplayer version 2?I want to download the latest version of newpipe which is still using exoplayer version 1 if it is available thanks 😊

litetex commented 3 years ago

@NSTAdventure I took a look into the commits and NewPipe was never shipped with ExoPlayer 1.

ExoPlayer was implemented in 2017 (β†’ https://github.com/TeamNewPipe/NewPipe/pull/486/files#diff-51a0b488f963eb0be6c6599bf5df497313877cf5bdff3950807373912ac1cdc9R48 ) and there it was already version 2. So as far as I know there is or ever existed no version with ExoPlayer 1.

If you have further questions, I think it would be great if you could ask these in the chat: https://github.com/TeamNewPipe/NewPipe/blob/dev/.github/CONTRIBUTING.md#communication This issue is definitely the wrong place for that.

ghost commented 3 years ago

@NSTAdventure I took a look into the commits and NewPipe was never shipped with ExoPlayer 1.

ExoPlayer was implemented in 2017 (β†’ https://github.com/TeamNewPipe/NewPipe/pull/486/files#diff-51a0b488f963eb0be6c6599bf5df497313877cf5bdff3950807373912ac1cdc9R48 ) and there it was already version 2. So as far as I know there is or ever existed no version with ExoPlayer 1.

If you have further questions, I think it would be great if you could ask these in the chat: https://github.com/TeamNewPipe/NewPipe/blob/dev/.github/CONTRIBUTING.md#communication This issue is definitely the wrong place for that.

thanks i will create issues later if i face lagging too on newpipe :) πŸ™

NoblePink commented 3 years ago

Another weird thing is that Android reported network activity around only 50 or 60KB/s, which is obviously not enough. I encountered that low speed on yt-dl, too. And yesterday I had stuttering even in firefox on my Laptop.

I suspect YT changed something on their side, too

I agree with @conkerts on the last line. When I tried to play videos externally with MPV I got extremely low speeds. Then I killed the Newpipe app and try again on the same video it was smooth again.

conkerts commented 3 years ago

I agree with @conkerts on the last line. When I tried to play videos externally with MPV I got extremely low speeds. Then I killed the Newpipe app and try again on the same video it was smooth again.

I wanted to add some "research" that I just did today (aka browsing the yt-dl issues), as like I said, I encountered that low speed on yt-dl, too. And the speed with 50-70kb/s is just suspiciously low, which I suspected is just throttling.

Well, turns out, the yt-dl guys have their own slowdown issue here: https://github.com/ytdl-org/youtube-dl/issues/29326

Esp check out this post from @awojnowski https://github.com/ytdl-org/youtube-dl/issues/29326#issuecomment-865985377 :

I have the solution for this issue. I do not have the bandwidth to actually implement it in the source, but this should be more than enough information to do so.

The issue is that YouTube is modifying the n query parameter on the video playback URLs in a very similar fashion as the signature cipher. There's a pure function in the player JavaScript which takes the n parameter as input and outputs an n parameter which is not subject to throttling.

As an example, let's look at https://www.youtube.com/s/player/52dacbe2/player_ias.vflset/et_EE/base.js. The code in question which modifies n is as follows:

a.C&&(b=a.get("n"))&&(b=Dea(b),a.set("n",b))}};

In this case, Dea is the function we are looking for: [... <weird js function cropped for brevity, see original post>] This does change with different player versions, so youtube-dl will need to extract this for every video that it fetches and then modify the n parameter as such. Hope this is helpful.

So the cat and mice game continues ... I hope this helps you guys @TeamNewPipe

Taratect commented 3 years ago

I'd like to mention that restarting the device puts a band aid to the problem until it recurs again.

Also, it happens when I watch vids in 2x timespeed.

dankxylese commented 3 years ago

I'd like to mention that restarting the device puts a band aid to the problem until it recurs again.

Killing the app is enough for me. You can force close it in app details or if you're on a custom rom bind "long press back" to kill apps to make this quicker.

I think why it works is that by restarting you're forcing a new connection to be made. Whether its a new server that's not limiting the stream, or NewPipe being able to decode the stream properly, resetting the connection works for me.

Maxwell12347842 commented 3 years ago

if i restart NewPipe it usually works for a few minutes, but then it re-appears again and again. it's really frustrating. i always watch youtube videos in bed before sleeping with NewPipe and because of this issue it is a nightmare. i'm now at a point where i download my "daily videos" i want to watch in bed to my phone so i don't need to stream them since its otherwise too annoying. it's so frustrating that youtube always needs to f*** around to try to prevent or annoy people. using yt-dl i had the same issues when i wanted to download videos.. it sucks so hard.

AudricV commented 3 years ago

Can you try the APK in TiA4f8R/NewPipe#1? There should be no buffering issues with it. Use it as a temporary fix for now.