[Youtube] 403 reemerge

[http403]

Checklist

• I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
• I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• I have read the FAQ and my problem isn't listed.
• I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• This issue contains only one bug.
• I have read and understood the contribution guidelines.

Affected version

0.25.2

Steps to reproduce the bug

1. Watch video
2. App crash approx 1 minute into the video
1. Open a video
2. (optional) Full screen
3. Pause the video at start or middle
4. Exit to home (but not quit the app)
5. Do something else (2+ hours)
6. Go back and resume the video

Expected behavior

Play the video continuously

Actual behavior

About 1 minute into the video after resuming, it will crash with 403.

Screenshots/Screen recordings

No response

Logs

Exception

• User Action: play stream
• Request: Player error[type=ERROR_CODE_IO_BAD_HTTP_STATUS] occurred while playing https://www.youtube.com/watch?v=WxLzoq-NMpY
• Content Country: GB
• Content Language: en-
• App Language: en_US
• Service: YouTube
• Version: 0.25.2
• OS: Linux samsung/r9qzh/r9q:13/TP1A.220624.014/G9900ZHU5EWE3:user/release-keys 13 - 33

Crash log

com.google.android.exoplayer2.ExoPlaybackException: Source error
	at com.google.android.exoplayer2.ExoPlayerImplInternal.handleIoException(ExoPlayerImplInternal.java:644)
	at com.google.android.exoplayer2.ExoPlayerImplInternal.handleMessage(ExoPlayerImplInternal.java:616)
	at android.os.Handler.dispatchMessage(Handler.java:102)
	at android.os.Looper.loopOnce(Looper.java:226)
	at android.os.Looper.loop(Looper.java:313)
	at android.os.HandlerThread.run(HandlerThread.java:67)
Caused by: com.google.android.exoplayer2.upstream.HttpDataSource$InvalidResponseCodeException: Response code: 403
	at org.schabi.newpipe.player.datasource.YoutubeHttpDataSource.open(YoutubeHttpDataSource.java:422)
	at com.google.android.exoplayer2.upstream.DefaultDataSource.open(DefaultDataSource.java:263)
	at com.google.android.exoplayer2.upstream.TeeDataSource.open(TeeDataSource.java:52)
	at com.google.android.exoplayer2.upstream.cache.CacheDataSource.openNextSource(CacheDataSource.java:796)
	at com.google.android.exoplayer2.upstream.cache.CacheDataSource.open(CacheDataSource.java:609)
	at com.google.android.exoplayer2.upstream.StatsDataSource.open(StatsDataSource.java:84)
	at com.google.android.exoplayer2.source.chunk.ContainerMediaChunk.load(ContainerMediaChunk.java:124)
	at com.google.android.exoplayer2.upstream.Loader$LoadTask.run(Loader.java:412)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1137)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:637)
	at java.lang.Thread.run(Thread.java:1012)

---

Affected Android/Custom ROM version

Android 13

Affected device model

Samsung Galaxy S21 5G FE

Additional information

I know the problem was declared fixed in TeamNewPipe/NewPipeExtractor#1084, but it is still happening.

This issue might look like #10329 but it is different. That issue is a result of 404, mine is a result of 403, thus I decided to open a new one.

Noted, this bahavior is not consistant, and for the span of 3 days of light use, I only encounter twice. It is hard to reproduce, and not as frequent as in 0.25.1.

Upon further usage, I sort of find the way to reproduce the crash. However, I have no idea if it's reliable.

I didn't apply the workaround in the release note.

[attilafekete73]

This happens to me too, but it does that every time I try to open a video. It plays for 1 minute, then it crashes.

[opusforlife2]

Let's see if more people encounter this.

[http403]

To all users, please use the thumbs up reaction on the main issue to signify you experience the problem unless you have additional information such as, reliably triggering the error, with detailed steps on reproducing it. Thank you.

[http403]

I updated the steps to reproduce the crash. Though I have no idea how reliable that is.

[AudricV]

Do something else (2+ hours)

Then the streaming URLs may have expired (URLs should be only valid for 21540 seconds), and in this case this issue would be a duplicate of #5730. You can still play the video for around 1 minute before getting the error as the player library, ExoPlayer, is configured to have the goal to buffer streams 50 seconds (the default value).

If you can still get sometimes this invalid response code when you start playing a video and after around 1 minute of playback, then it means that YouTube is disabling our last known workaround to use the Android client.

We wouldn't be the only app affected again by this issue, reVanced would be too for instance, but contrary to it, we have the freedom to use almost every YouTube client we want.

[http403]

@AudricV Thanks for letting me know, and sorry for I didn't search thorough enough.

This proves I didn't find the correct way to reproduce the issue.

@Haitham-7 @openmoth @attilafekete73 and others, as you stated you experienced the issue, could you please share the crash log and possbility step to reproduce? This will help to judge if Google did something new or just a duplicate. Thank you.

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[github-actions]

This issue has been automatically closed because there has been no response to our request for more information from the original author. With only the information that is currently in the issue, we don't have enough information to take action. Please reach out if you have or find the answers we need so that we can investigate further.

[opusforlife2]

I don't see the need to reopen this because the error clearly isn't occurring for everyone like last time, but only intermittently, which is to be expected.

[shaohme]

I don't see the need to reopen this because the error clearly isn't occurring for everyone like last time, but only intermittently, which is to be expected.

Would it be trivial to make NewPipe catch this error instead, show a generic error, (perhaps retry), instead of "crashing" in the background?

[opusforlife2]

Most network based errors need to be reworked, actually. But it can't be done easily, otherwise, for example, users will keep retrying and never know what's going wrong.

[squishyu]

I don't see the need to reopen this because the error clearly isn't occurring for everyone like last time, but only intermittently, which is to be expected.

Would it be trivial to make NewPipe catch this error instead, show a generic error, (perhaps retry), instead of "crashing" in the background?

I support a solution like this. I've been getting this error every day for months, whenever my phone switches between WiFi and data (leaving the house)

When listening to a playlist, it just skips to the next song instead of retrying.

[http403]

I don't see the need to reopen this because the error clearly isn't occurring for everyone like last time, but only intermittently, which is to be expected.

Would it be trivial to make NewPipe catch this error instead, show a generic error, (perhaps retry), instead of "crashing" in the background?

I think this issue will be appropriate to address by opening a new issue.