YouTube is activelly chasing this repo

[jonjmoreira]

I've been using Pipepipe for almost 5 years!(?), but never really contributed to this project.

Recently, about a month ago, I can't really watch any sequence of videos 'cause there's this

1. Pipepipe signaling that YT needs x seconds to load V
2. I can play the midia (may it be video or audio only), but it stops t 0:59
3. The devs of this project probably have used something to do with stories, which have that exact maximum timespan/lifespan

The keyword is lifespan. I hope there's no insider in this project, but, if not, Google is actually activelly monitoring and acting upon changes on this repo.

What do you think? How could we maintain this an open project, but not allowing the vendor to see it?

is this a discussion that will tead us to a complete, Matrix Movie-like thing? Can we not live without owners? Will we always be slaves to ... ?

[jonjmoreira]

And another provocation: is this actually a turned-on Google repo that aims blocking? Are we baits? Test subjects?

[Priveetee]

I understand the concern, but honestly this goes much too far from a real playback bug to claims about an insider or PipePipe being some kind of Google bait.

The problem around 0:59 was already tracked in #2761. The reports show SABR attestation being required with status=3, followed by repeated server backoff instructions. The wait itself comes from YouTube, but getting stuck in an endless wait loop was the bug. There is no evidence connecting this to the lifespan of Stories.

To avoid another confusion, beta5 does contain an Android Reel request used as a fallback. However, it was added on August 6, after the original 59-second reports, and is only used when the primary stream extraction fails. It did not cause the SABR loop experienced by users on 5.2.4.

Of course Google can read a public repository, just like anyone else. We already work knowing that public implementations can be studied and that YouTube may change its behaviour. That is very different from having evidence that Google is specifically chasing this repo or that a contributor is an insider.

There is also no way to keep a project open source while preventing one particular company from reading it. Making the code private would only make PipePipe no longer open source, and the APK and network traffic could still be analysed anyway.

Please do not accuse contributors of being insiders, baiting users or secretly working for Google without evidence. People are spending their free time trying to keep the app working.

The current stable release is still 5.2.4, but 5.2.5-beta5 was released before this discussion and contains major YouTube changes. Please test beta5 first. If the problem remains, provide the PipePipe version, selected endpoint, login state, affected video URL and generated error report. That gives us something real to investigate.

Reporting guide:

https://priveetee.github.io/Docs-PipePipe/issues/reporting.html

YouTube playback guide:

https://priveetee.github.io/Docs-PipePipe/issues/youtube-playback.html

[jonjmoreira]

Thank you for your reply, Priveetee. Honestly, that answer clarifies many things abut the issue. It wasn't the intention to frame nor blame anyone, I'm really sorry that it sounded like that.

Really glad that you took that discussion seriously and actually answered it with proper manners! Thanks again, I'll keep in mind not to make such unfounded claims next time.

[Priveetee]

No worries, and thx u for understanding :)

Just a small update: the 59-second issue has now been traced to a new YouTube attestation requirement, and a fix is available for review in InfinityLoop1308/PipePipeClient#86.

In a way, this also answers part of your original question. Yes, YouTube can read public code, but keeping the project open also allows people to share findings and help each other when something changes. We cannot hide an open-source project from one company, but making it public is also what helps it survive :)