-
Notifications
You must be signed in to change notification settings - Fork 143
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better Player fetch #4089
Better Player fetch #4089
Conversation
Next version have just a workaround for login required, i have totally rewrited much code, now it work perfectly. |
That's great. Btw, the 0.6.57 seems to slow down the playback a lot. I notice some code being run multiple times but I did'nt have time to take a look. Can you check again? |
Yes I'll look into soon, thanks. |
One important thing, innertube and all modules in extensions are shared with the desktop project. It is best to avoid adding exclusive components in android by adding them directly into innertube. Thanks for your contribute. |
All files were created inside extensions/innertube, I created new packages because I didn't wanna break the working ones and for ease of reverse in case of failing |
yep |
I forgot to mention, the commits are made to be working with different platforms, I already tested it on pc and android so you don't have to worry about that |
Ok thanks |
After new release please re check this, thanks |
I think that this not necessary from now, YTM api seems to be only with login... working progress .. |
I have done some rework on the request side of this app (Innertube)
Request headers
First of all, I update it to match YouTube Internal Clients's example
Then, I removed api key from default request. This is reserved for retires
Player body
As reported in YouTube Internal Clients#3. YouTube may request
androidSdkVersion
,racyCheckOk
, as well ascontentCheckOk
in the body so I went a head and added them with default valuesConclusion
This is not a fix, just a workaround. As I observed, it only reduce the chance of getting "LOGIN_REQUIRED" but I think the result is really biased. Thus, I need more feedback to draw real conclusion.
Also, this only prevent YouTube from blocking from accessing the song at the beginning.
As far as my understanding, we are using Player with fetch song's stream by giving it the URL.
This makes it harder to hack since we don't have control of the data stream. In order to workaround this, we need a new Player that can give us direct access to the data stream.
What's next
I'm planing to do some rework with the response templates. Right now it's overwhelmed with nullable values.
My initial idea is that we return every request as an interface
Response
. Then we have classes likeErrorResponse
or more specificLoginRequiredResponse
etc. andPayloadResponse
orPlayerResponse
.Each response only carries needed values and they are less likely to be null.
It's also easier to debug since we can check if Response falls into what category to take appropriate action