-
-
Notifications
You must be signed in to change notification settings - Fork 78
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
"Add" button not working when trying to add a track #262
Comments
Davy (https://www.facebook.com/openwhyd/inbox/?mailbox_id=1156477841040143&selected_item_id=1690425813) also reported that the Chrome extension does not work anymore, probably for the same reason. |
Indeed, our historic YouTube API key (project number I'm currently creating new YouTube API keys, one per file where the old one was mentionned, so I can track how many calls and sent thru each of them, from Google APIs Console. |
Note: it seems that new API keys take some time to be active. Until then, API calls (e.g. from http://localhost:8080/search?q=/yt/aZT8VlTV1YY) fail with status {
error: {
errors: [
{
domain: "usageLimits",
reason: "accessNotConfigured",
message: "Access Not Configured. YouTube Data API has not been used in project 345430738996 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=345430738996 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry.",
extendedHelp: "https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=345430738996"
}
],
code: 403,
message: "Access Not Configured. YouTube Data API has not been used in project 345430738996 before or it is disabled. Enable it by visiting https://console.developers.google.com/apis/api/youtube.googleapis.com/overview?project=345430738996 then retry. If you enabled this API recently, wait a few minutes for the action to propagate to our systems and retry."
}
} |
Closes #262. ## What does this PR do / solve? Since Google disabled our historic YouTube API Key, on February 20th, users have not been able to add YouTube tracks to their Openwhyd profile. ## Overview of changes Create dedicated YouTube API Keys for each component. ## How to test this PR? ```sh $ git pull $ docker-compose up --build --detach $ nvm use $ npm install $ npm run docker:test ```
…outube (#264) Closes #262. ## What does this PR do / solve? Since Google disabled our historic YouTube API Key, on February 20th, users have not been able to add YouTube tracks to their Openwhyd profile. PR #263 did not seem to help. Probably because quotas were broken. ## Overview of changes - Create a new Google Project to hold new YouTube API Keys. - Create dedicated YouTube API Keys for each component. ## How to test this PR? ```sh $ git pull $ docker-compose up --build --detach $ nvm use $ npm install $ npm run docker:test ```
## [1.21.1](v1.21.0...v1.21.1) (2020-02-28) ### Bug Fixes * **#212:** user can add tracks thanks to new google api account for youtube ([#264](#264)) ([6da7db7](6da7db7)), closes [#212](#212) [#262](#262) [#263](#263) * **#262:** user can add YouTube tracks (when new keys are active) ([c1d7a85](c1d7a85)), closes [#262](#262) [#262](#262)
News: here are some stats of how the different Youtube API keys have been used since yesterday (#264) The bookmarklet (i.e. Chrome Extension) is the what consumes the most quota. As it makes our new Google Project over-quota, I'm opening a new one just for this. |
The bookmarklet (i.e. Chrome Extension) is the what consumes the most quota. As it makes our new Google Project over-quota, I'm opening a new one just for this. See #262 (comment)
The track edition/add dialog (i.e. `postEditV2.html`) is the second biggest consumer of our YouTube API usage quota. As it makes our new Google Developer Project over-quota, I'm opening a new one just for this: `openwhyd-1`. See #262.
Contributes to #262. ## What does this PR do / solve? As mention in #262 following the reduction of our YouTube API quota, we need to make several changes to the bookmarklet in order to save some quota while keeping a good user experience. E.g. track titles should be extracted from the page instead of queried from YouTube API. As these changes are quite structural and may introduce bugs in the bookmarklet, and as we don't have time to test it manually after each change, it's time to refactor the code in order to make that code testable by automated unit tests. This PR is the first step of that refactor: it makes the bookmarklet loadable from Node.js. ## Overview of changes See the diff, and disable the display of whitespace changes. - export `detectTracks({ window, ui, urlDetectors })`, `makeFileDetector()` and `makeStreamDetector(players)` - bump to bookmarklet v2.4 (from v2.3) - add a first unit test ## How to test this PR? ```sh $ nvm use $ node_modules/.bin/mocha test/unit/bookmarklet-tests.js $ docker-compose up --build -d $ npm run docker:seed && node_modules/.bin/wdio wdio.conf.js ``` Also, you can test the bookmarklet manually, from your web browser, by following the instructions provided in the unit test file: https://github.com/openwhyd/openwhyd/pull/280/files?diff=split&w=1#diff-c8dc146d6906e24b2298327e5628d90aR23
Contributes to #262. Follow up of #280. ## What does this PR do / solve? As mentioned in #262 following the reduction of our YouTube API quota, we need to make several changes to the bookmarklet in order to save some quota while keeping a good user experience. E.g. track titles should be extracted from the page instead of queried from YouTube API. As these changes are quite structural and may introduce bugs in the bookmarklet, and as we don't have time to test it manually after each change, it's time to refactor the code in order to make that code testable by automated unit tests. This PR is the second step of that refactor: it enables adaptive metadata enrichment for the page itself (e.g. youtube track page), while preventing duplicates in the results. ## Overview of changes See the diff, and disable the display of whitespace changes. - add `detectYouTubePageTrack()` - group ui calls - bump to bookmarklet v2.5 (from v2.4) - add unit tests ## How to test this PR? ```sh $ nvm use $ node_modules/.bin/mocha test/unit/bookmarklet-tests.js $ docker-compose up --build -d $ npm run docker:seed && node_modules/.bin/wdio wdio.conf.js ``` Also, you can test the bookmarklet manually, from your web browser, by following the instructions provided in the unit test file.
Contributes to #262. Follow up of #281 and #282. ## What does this PR do / solve? After YouTube reduced our API quota, we resorted to specifying "(YouTube track)" as the title of tracked extracted from YouTube pages using the bookmarklet, in order to save some quota. This PR intends to determine the actual name of the track by extracting text from the DOM, and therefore to get rid of those "(YouTube track)" titles on newly added tracks. ## Overview of changes - completely get rid of forced "(YouTube track)" titles 🥳 - add feat: "return a track with metadata from a YouTube page that lists that track as a link" - add feat: "return a track with the expected name when that track was found as a link from a YouTube page" (i.e. remove noise from title) - add feat: "return the page's track with metadata from a YouTube page when the same track is also listed in the page with less metadata" - rename `detectPlayemStreams()` --> `detectPlayableStreams()` + integrate `YOUTUBE_PLAYER` (partially imported from PlayemJS, without the API query part) in the bookmarket, and use it also from tests => first step in progressively getting rid of Playem for track detection - normalize the way text is extracted from DOM - cleaning up logs from bookmarklet - simplify logic and make code a little bit more readable overall ## How to test this PR? ```sh $ nvm use $ node_modules/.bin/mocha test/unit/bookmarklet-tests.js $ docker-compose up --build -d $ npm run docker:seed && node_modules/.bin/wdio wdio.conf.js ``` Also, you can test the bookmarklet manually, from your web browser, by following the instructions provided in the unit test file.
Contributes to #262. The goal is to make the bookmarklet easier to read, understand and maintain.
We greatly reduced the usage of YouTube API, notably by making the boomarklet extract track info from the DOM (see PR #285) => closing. (at least for now) |
Contributes to #262. Let users know that we've made some progress with YouTube issues. <img width="386" alt="Capture d’écran 2020-03-13 à 15 43 42" src="https://user-images.githubusercontent.com/531781/76631210-94af0880-6541-11ea-8e32-6e95461cb911.png">
News about YouTube API QuotasWe've reduced our number of google projects to just 3:
The restriction of API keys and merging of google projects is still fresh (i.e. yesterday and the day before), but quota usage looks better, so far:
|
As reported by Tut Tut, we've gone over-quota again since yesterday: Most requested endpoints: Usage per API key: |
=> I restricted both keys so that we can only be used by our production openwhyd instance. |
Note: on November 3rd, 2020, I received the following email from YouTube:
Which is weird because:
|
## What does this PR do / solve? PlayemJS has been maintained for Openwhyd, to play and detect tracks, by communicating with the APIs of the streaming sources we support. While PlayemJS has supported more sources than most alternative players we have found online, its codebase has become hard to maintain, so it suffers from a lack of updates, which lead to numerous problems taking a lot of time and effort to fix: e.g. #272, #262, #192, #190, #143, #132, #128, #16... In order to simplify Openwhyd's codebase and make it easier for us to replace PlayemJS with an alternative, let's start by trying to remove it from the bookmarklet and see if anybody misses it from there.
## [1.43.1](v1.43.0...v1.43.1) (2020-11-28) ### Bug Fixes * **bookmaklet:** Transpile changes form [#408](#408) to JS ([59f6f98](59f6f98)) * **bookmarklet:** Re-add PlayemJS in bookmarklet ([#408](#408)), for track detection ([8fd1a3e](8fd1a3e)) * **bookmarklet:** Remove PlayemJS from bookmarklet ([#408](#408)) ([7296b21](7296b21)), closes [#272](#272) [#262](#262) [#192](#192) [#190](#190) [#143](#143) [#132](#132) [#128](#128) [#16](#16)
Describe the bug
"Add" button not working when trying to add a track.
Nothing happens, except the following errors in the javascript console:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The track should be added, and the "add" dialog disappear.
Screenshots
Platforms:
Additional context
Reported by Monstance (https://www.facebook.com/openwhyd/inbox/?notif_id=1582581798335905¬if_t=page_message_reminder&mailbox_id=1156477841040143&selected_item_id=828895359)
Could be related to the fact that our YouTube API key was shutdown by Google.
The text was updated successfully, but these errors were encountered: