Songs play only within release page about beatbump HOT 12 OPEN

I don’t touch those at all. The computation cost was way too high and resulted in way too long of load times, so I use the Android client information to send the request (as seen here), which will bypass the need to do any deciphering.

The benefits of this method are obvious, but with how YouTubes API tends to work in ways I’d never have expected it to, it makes me question if I am doing a step or two somewhere that works, until it magically decides to break only partially lmfao

At this very moment I was about to start modularizing Beatbumps API, so hopefully a consistent singular “point of truth” will at least shed some sort of light on this!

from beatbump.

So, as part of the rewrite, I’m also going to be doing my API requests more “properly”. YouTube sends a CSN (Client Screen Nonce) on some requests, and some other information they tend to use on each request.

I’m going to work on implementing their CSN algorithm (no user info is used to make this), as well as sending the other information where needed. Hopefully this change will help the reliability, I’ll update when I add it in

EDIT: just to clarify, I’m working on this now

from beatbump.

I've been looking into this for the past 2 hours, and at least on the dev server it's being very strange only on Firefox. So i'm not sure what's exactly wrong, seeing as the https://xxxx.googlevideo.com domain is the one that fails. Even weirder that the same songs will play but only on the release page.

Can you do me a favor, and next time it fails, collect some data for me. Either as screenshots or you can reply with the JSON directly. But it'd be great if I could get the response headers for both next.json and player.json, as well as the JSON bodies they return.

Also, use this region restriction tester -- whenever the https://xxxx.googlevideo.com domain fails, copy the very last googlevideo URL and paste it in Notepad or something. In that URL there should be two query parameters &ip and &mip, the first one will be the Cloudflare data center that you're connected to -- the second one is yours (not really needed since you already know where you live). Verify if the Cloudflare data center's IP is based from a country that's under the Allowed list that the tester provides.

Looking forward to hearing back so I can see what's causing this!! Thanks for the video of the network tab too!

from beatbump.

Thanks for the reply.

First things first: a couple of hours ago everything was working-ish as expected: I was able to play some songs 22 hours ago NEVER played. However, things are back to the buggy state now.

Also, use this region restriction tester [...]

Things seem OK here, my country (Italy, which is also the one the Cloudflare data center is connected to) is in the Allowed list.

search page: beatbump.ml_Archive [22-04-03 11-21-04].txt
release page: beatbump.ml_Archive [22-04-03 11-22-21].txt

from beatbump.

How long has this been occuring, if you'd have an estimated time range? The only thing I could think of would be potentially the way I handle rewriting the stream's URL to immediately redirect. Although it's still weird that it breaks on the search page. Within the past few days I've gone back to rewriting the urls to initially go to https://redirector.googlevideo.com, for about 2 months prior to that I was just using the URLs YouTube sent back directly. Prior to that I was only using the redirector.googlevideo.com trick.

Unsure if that'd help you recall any sort of details from the past, but I'm jotting down potential ideas as to causes. I'm also experimenting with the dev server, so hopefully I'll find some sort of pattern in when something breaks so I can figure out why it breaks

from beatbump.

How long has this been occurring, if you'd have an estimated time range?

Well, I found this project a couple of months ago I'd say, I tried it and I felt disappointed because it didn't play any song.
Then, I started a similar project for Android (native) a couple of days ago, so I re-tested Beatbump to see how it worked and here we go.

I also tried using your api through http clients such as Retrofit and ktor, and even there I got 403s half of the time.

Question aside, where in your code base do you handle signatureTimestamp and cipherSignature?

from beatbump.

Let me know if you notice any changes in the behavior, since over the next week or so I should be making some changes, whether or not they’ll work is unknown — but hopefully they do.

Just as a side note, have you tried a Chromium based browser? Looking at the logs you sent, if I’m remembering correctly, I believe I saw that the server responded with a 403 — and some of the headers didn’t seem right to me. Not sure if that’s a possibility or not though

from beatbump.

Hi, yep, it also happens on Chromium. I couldn't find a way to reproduce it. It looks like it's completely random

from beatbump.

E.g.: in this video I open Chromium several times (either in normal or incognito mode)... it worked 4/7 times

from beatbump.

Has it improved at all? I’ve been making some changes that potentially could’ve had an effect, but I’m not sure if they worked or not

from beatbump.

Hmm, not sure - all I can say is on Chromium works better

from beatbump.

Another update:

I’ve started the API rewrite which can be found here: https://github.com/snuffyDev/Beatbump/blob/rewrite/src/routes/api/_api/request.ts

hoping once I finish it, that this would be solved, but still is hard to tell at this moment

from beatbump.