Closed CemraJC closed 6 years ago
I get the same error with the Docker image.
A temporary fix would be to generate your own YouTube API key (from https://developers.google.com/youtube/registering_an_application) and replace the one in here: https://github.com/ritiek/spotify-downloader/blob/f943080edb7706cdfbc1478954c396dd803a0a35/core/youtube_tools.py#L10-L11
@linusg, @vn-ki (and anyone reading this) what do you guys think? There are a couple of things we could do:
@ritiek I never thought we would exceed the quota limit! mpsyt does not have any issues regarding quota. (Maybe it's because mpsyt uses an old api key which has 50 times more quota points).
Quoting stackoverflow
You can use 30,000 units/second/user and 1,000,000 per day.
Our most quota intensive operation is search (100 quota points per operation) which means each user can download a maximum of 300 songs and every user combined can download a maximum of 10,000 songs.
Now, my take on the proposed solutions,
What do you think?
@ritiek First of all, let's narrow down the source of the problem. I believe it's because of the rising popularity of spotify-downloader we now hit the quota limit when too many people actually have used the tool on a day. Right?
If so, option 1 seems to be a fairly bad workaround: how long does it take until both keys exceed their limit on a day? Some weeks, some months? You see where I'm going here, I believe maintaining a list of API keys is not exactly what we want. Option 2 is in my opinion the most reliable one, as users will have their own quotas. Option 3 seems the most practical to me.
I would go for 3 and making 2 optional. Which would require a good level of abstraction but I believe we can do it, and it would still bring speed and reliability improvements to users having their own key.
So I basically agree with @vn-ki here 👍 Any chance we can monitor the quota point level? It slowly decreasing would indicate a quite heavy but regular usage. It going down very quickly at one point would indicate abuse/high overuse by an individual.
Any chance we can monitor the quota point level?
@linusg, I believe @ritiek can, in his project console.
Any chance we can monitor the quota point level?
I don't think I remember what account I used to generate API keys anymore but even if we could monitor, we couldn't have done much. Since, as @vn-ki mentioned:
Our most quota intensive operation is search (100 quota points per operation) which means each user can download a maximum of 300 songs and every user combined can download a maximum of 10,000 songs.
300 songs for user per day is not really an abuse/overuse.
So far, scraping YouTube by default and additionally have an option for users to set an API key for better stability/faster response time seems a good idea to me.
As of #250, the tool will scrape YouTube by default (uses API quota only when fetching video details with pafy.new()
) and users may switch over to YouTube API completely (for making searches as well) after setting their API key in config.yml
.
Thanks everyone for your replies! I have to say, this project is run much better than many others I know of - I hardly expected a response, let alone a full conversation, a fix and a new release not more than 3 days after I posted this issue!
@ritiek I'll go generate my own API key and test it all out when I get back home on Monday. Either way, I would say that the issue has been appropriately addressed and the solution should scale as intended.
Thanks again! You guys are awesome 😄🎉
@CemraJC Yep thanks, let us know how it goes. We'll close this issue then.
@ritiek Just ran a test then with a 50 song playlist, after generating my own API key. Speeds are good, no worries with the API quota!
Thanks again!
@CemraJC thanks for letting us know! Glad it works smoothly. @ritiek really good work, and nice to finally see you around here again :smiley:
I know the issue is closed :D but it is the most relevant thread I think
what is the default behavior of script? web scraping or API calling?
I have a doubt on script method, currently I wrote an extra node layer on top of spotdl CLI, using queue system and streaming files, but even after 5 attempts with 15-30 sec backoff/delay script will return 403 error, i was wondering script is using web scraping, but it seems we are using youtube API and it exceeded quota.
@SaeedSheikhi I'll explain a bit. We default to web-scraping for making video searches on YouTube (what this issue was originally about). Once the best matching video is selected, we use pafy to get the audiostream off this video. It is pafy which makes use of the YouTube API and relies on youtube-dl to fetch the audiostream.
And as I tried a few days ago, the problem doesn't seem to be related to exceeded quota. It seems the problem is with YouTube itself which somehow generates audiostream URL which gives us a 403 forbidden when trying to access it. By audiostream URL, I mean the big URL which looks something like:
https://r1---sn-8pgbpohxqp5-ac5l.googlevideo.com/videoplayback?expire=1557779330&ei=IX_ZXIjqNcfjVMiIgIgI&i...
Also see #550 for more info.
@ritiek Thanks for your explanation, i did some investigation and walking around issues, read both #550 & #246, finally I end up here to post a comment. for a temporary solution, fixed that by implementing a queue layer with 30 sec backoff and 15 times attempts, luckily most of the time script can reach the media on 12-14th attempt :D but at the end it required a hard work to make a CLI calls and attempts automatic for most of the users.
What is the purpose of your issue?
Description
When attempting to download music from a previously-parsed spotify playlist, the program exits with an error about "403: The request cannot be completed because you have exceeded your quota".
If you need any further information, please let me know!
Log