TeamNewPipe/website
1
0
Fork 0
mirror of https://github.com/TeamNewPipe/website synced 2025-10-06 00:22:38 +02:00
Code Issues Releases Wiki Activity

Apply review suggestions

Browse Source
This commit is contained in:
Stypox
2025-02-23 15:48:00 +01:00
parent 8ec1535880
commit 8274b87a33
1 changed files with 13 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
_posts/2025-02-16-newpipe-0.27.6-rewrite-team-states.md
View File

@@ -9,7 +9,7 @@ image: newpipe
excerpt_separator: <!-- more -->
---
TLDR: NewPipe 0.27.6 fixes the YouTube issues by performing the integrity checks now required by Google; NewPipe is being refactored heavily on the `refactor` branch and you can help and provide feedback on a nightly version; NewPipe will soon have a new completely rewritten player; the NewPipe team is struggling to keep up with the project's demands due to members not having enough time.
TLDR: NewPipe 0.27.6 fixes the YouTube issues by performing the integrity checks now required by Google; NewPipe is being refactored heavily on the `refactor` branch and you can help and provide feedback on a nightly version; NewPipe will soon have a new completely rewritten player; the NewPipe team is struggling to keep up with the project's demands due to dwindling free time of its members.
<!-- more -->
@@ -53,7 +53,7 @@ As explained above, in mid 2024 we finally started working on the awaited refact
<figcaption class="text-center">A showcase of the NewPlayer test app</figcaption>
</figure>
As explained in [this previous blogpost]({{ site.baseurl }}/blog/pinned/announcement/schabi-contract/), NewPipe's current player is **buggy and mis-structured**. [Schabi was contracted]({{ site.baseurl }}/blog/pinned/announcement/schabi-contract/) to rewrite it from scratch [by the NewPipe e.V.](https://newpipe-ev.de/posts/2024-06-23_3rd_board_meeting.html), and he delivered a great implementation in October 2024. The new player (or rather, *NewPlayer*) uses [media3](https://developer.android.com/media/media3) for playback (a successor of ExoPlayer), and was built in a separate repository to ensure separation of concerns and so that other apps can possibly use it too. You can **read Schabi's announcement** [here](https://github.com/TeamNewPipe/NewPipe/issues/11603), find the source code [here](https://github.com/TeamNewPipe/NewPlayer) and download a test APK from [here](https://github.com/TeamNewPipe/NewPlayer/releases/). Now [the e.V. made a contract](https://newpipe-ev.de/posts/2024-12-03_hiring_contributor.html) with [Profpatsch](https://github.com/Profpatsch), who picked up Schabi's work and is integrating NewPlayer into NewPipe. Let's wish them well in their work!
As explained in [this previous blogpost]({{ site.baseurl }}/blog/pinned/announcement/schabi-contract/), NewPipe's current player is **buggy and mis-structured**. [Schabi was contracted]({{ site.baseurl }}/blog/pinned/announcement/schabi-contract/) to rewrite it from scratch [by the NewPipe e.V.](https://newpipe-ev.de/posts/2024-06-23_3rd_board_meeting.html), and he delivered a great implementation in October 2024. The new player (or rather, *NewPlayer*) uses [media3](https://developer.android.com/media/media3?hl=en) for playback (a successor of ExoPlayer), and was built in a separate repository to ensure separation of concerns and so that other apps can possibly use it too. You can **read Schabi's announcement** [here](https://github.com/TeamNewPipe/NewPipe/issues/11603), find the source code [here](https://github.com/TeamNewPipe/NewPlayer) and download a test APK from [here](https://github.com/TeamNewPipe/NewPlayer/releases/). Now [the e.V. signed a contract](https://newpipe-ev.de/posts/2024-12-03_hiring_contributor.html) with [Profpatsch](https://github.com/Profpatsch), who picked up Schabi's work and is integrating NewPlayer into NewPipe. Let's wish them and us a lot of success with their work!
*If you have experience with media3, ExoPlayer or media apps on Android, we'd love to get some feedback from you on the architecture and lifecycle* 😌
@@ -63,7 +63,7 @@ As explained in [this previous blogpost]({{ site.baseurl }}/blog/pinned/announce
NewPipe's codebase dates back to 2015, when the Android library landscape was a lot different. New architectural patterns, new good practices, new programming languages and new libraries have emerged since then, and we want to benefit from them in the refactored codebase:
- NewPipe is still a mix of Java and Kotlin, and we would like to complete the **move to Kotlin**. This means making use of Kotlin's language features, like nullability checks, but also switching from RxJava to the built-in coroutines.
- We want to migrate every **UI** component to **[Jetpack Compose](https://developer.android.com/compose)**, a UI toolkit which employs a *declarative* approach as opposed to the default Android XML-based *imperative* approach. It makes development significantly faster and less error-prone, since it allows writing UI components directly in Kotlin and favours having a single source of truth for the app's state.
- We want to migrate every **UI** component to **[Jetpack Compose](https://developer.android.com/compose?hl=en)**, a UI toolkit which employs a *declarative* approach as opposed to the default Android XML-based *imperative* approach. It makes development significantly faster and less error-prone, since it allows writing UI components directly in Kotlin and favours having a single source of truth for the app's state.
- We want to embrace the **Model-View-ViewModel** architectural pattern (the standard one for Android apps).
- We want to use Hilt for **dependency injection**, use `DataStore` instead of `SharedPreferences`, modernize the build system, …
@@ -71,7 +71,7 @@ NewPipe's codebase dates back to 2015, when the Android library landscape was a
While migrating the UI to Jetpack Compose, we want to take the opportunity to redesign the most used UI components and make sure they are *easy* to understand, *convenient* to use, *powerful*, and *nice* to see. We also wish to adopt Material 3.
Users often ask for new features, and when they are told that those features would be in the way of the average user, they ask for **settings toggles** to tune the app's behavior. While having customizability is good, *too much of it is almost equivalent to not having it at all*: if there are pages upon pages of settings, would you really go through and try what each of them does? Moreover, more settings implies more possible configurations, which implies more code to maintain, which implies more bugs.
Users often ask for new features, and when they are told that those features would be in the way of the average user, they ask for **settings toggles** to tune the app's behavior. While having customizability is good, *too much of it is almost equivalent to not having it at all*: If there are pages upon pages of settings, would you really go through and try what each of them does? Moreover, more settings implies more possible configurations, which implies more code to maintain, which implies more bugs.
<figure class="right">
<img src="{{ site.baseurl }}/img/screenshots/rewrite_1.png">
@@ -105,7 +105,7 @@ The first component to be migrated to Jetpack Compose and Material 3 was the **r
<figcaption>The revamped comment section with replies shown in a bottom-sheet dialog</figcaption>
</figure>
[@Isira-Seneviratne](https://github.com/Isira-Seneviratne) and [@Stypox](https://github.com/Stypox) worked (again) together on the reimplementation of the **About screen** (*that's the most useful part of the app, right?*). In particular they made use of the [AboutLibraries](https://github.com/mikepenz/AboutLibraries) Gradle plugin which automatically compiles information on the dependencies which can be accessed at run time, saving the developers of having to hardcode details about the libraries used.
[@Isira-Seneviratne](https://github.com/Isira-Seneviratne) and [@Stypox](https://github.com/Stypox) worked (again) together on the reimplementation of the **About screen** (*that's the most useful part of the app, right?*). In particular they made use of the [AboutLibraries](https://github.com/mikepenz/AboutLibraries) Gradle plugin which automatically compiles information on the dependencies which can be accessed at run time. This saves the developers from having to hardcode these details about the libraries used in NewPipe.
<figure class="screenshot-list">
<img src="{{ site.baseurl }}/img/screenshots/rewrite_4.png"/>
@@ -120,7 +120,7 @@ The first component to be migrated to Jetpack Compose and Material 3 was the **r
<figcaption class="text-center">Look how cute the new kaomojis are!</figcaption>
</figure>
Onto the under-the-hood changes, [@snaik20](https://github.com/snaik20) introduced Jetpack Compose in the app and set up the initial theming support. [@JL0000](https://github.com/JL0000) moved dependency declarations from Gradle scripts to [version catalogs](https://developer.android.com/build/migrate-to-catalogs), making dependency management easier. [@Isira-Seneviratne](https://github.com/Isira-Seneviratne) changed the image loading library from Picasso to Coil 3, which has better support for the Compose environment.
Onto the under-the-hood changes, [@snaik20](https://github.com/snaik20) introduced Jetpack Compose in the app and set up the initial theming support. [@JL0000](https://github.com/JL0000) moved dependency declarations from Gradle scripts to [version catalogs](https://developer.android.com/build/migrate-to-catalogs?hl=en), making dependency management easier. [@Isira-Seneviratne](https://github.com/Isira-Seneviratne) changed the image loading library from Picasso to Coil 3, which has better support for the Compose environment.
Thank you to everyone who contributed, with big or small changes! As you can tell also by looking at [the GitHub Project](https://github.com/orgs/TeamNewPipe/projects/18/views/1), there is plenty of stuff to choose from if you wish to contribute 😊 (though make sure to [get in touch](#conclusion-and-contact) with the team before starting to work).
@@ -165,17 +165,19 @@ Without valid integrity tokens, obtained after passing integrity checks, you can
### Breaking change 2: invalid iOS player responses (fixed in 0.27.5)
YouTube started to require a **visitor data** string. It is used to identify in a unique way the session of a user and is returned by YouTube servers the first time a client makes a request. If a visitorData is not provided, YouTube returns a *"Sign in to confirm that you're not a bot"* error.
YouTube started to require a **visitor data** string in some requests with some clients (the ones used to get streams). It is used to identify in a unique way the session of a user and is returned by YouTube servers the first time a client makes a request. If a visitor data is not provided, YouTube returns a *"Sign in to confirm that you're not a bot"* error.
To fix this issue, [@Theta-Dev](https://github.com/Theta-Dev) opened [a PR](https://github.com/TeamNewPipe/NewPipeExtractor/pull/1262) where a random visitorData is generated every time.
To fix this issue, [@Theta-Dev](https://github.com/Theta-Dev) opened [a PR](https://github.com/TeamNewPipe/NewPipeExtractor/pull/1262) where a random visitor data is generated locally every time.
### Breaking change 3: invalid iOS player responses (fixed in 0.27.6)
A couple of weeks ago, YouTube started to **reject randomly generated visitorData**, and so required visitorData generated by their servers. NewPipe's extractor now makes requests to get a visitorData from YouTube for every player request we make, regardless of the client (just in the case this change applies to all clients at some point).
A couple of weeks ago, YouTube started to **reject randomly generated visitor data**, and so required visitor data generated by their servers. NewPipe's extractor now makes requests to get a visitor data from YouTube for every player request we make, regardless of the client (just in the case this change applies to all clients at some point).
As YouTube is requiring integrity checks in their iOS client that we are not able to pass for most of formats returned, we removed usage of this client in NewPipe. This unfortunately means that livestreams cannot be rewinded for more than 30 seconds, since the *web* client does not allow to rewind livestreams in HLS manifests for more than this duration. <!-- TODO please check if correct -->
YouTube is requiring integrity checks in their iOS client for most formats returned. We are not able to pass them, so we removed usage of this client in NewPipe. This unfortunately means that livestreams cannot be rewinded for more than 30 seconds, since the *web* client does not allow to rewind livestreams in HLS manifests for more than this duration (while the iOS client allows to rewind up to 1 hour).
The DASH manifests returned by the *web* client are known have a broken format and cannot be played directly, but we found a workaround which we should be able to ship in the next release, allowing to rewind up to 4 hours! (unless the creator disabled rewinding)
The DASH manifests returned by the *web* client are known to be kind of broken and cannot be played directly in the app, but we found a workaround which we should be able to ship in the next release, allowing to rewind up to 4 hours!
All of these durations apply unless the creator disabled rewinding.
## Donations are awesome