For the last few days, when I try to watch any video on tube.cadence.moe, I get ``` Error Could not extract video info. Instance is likely blocked. RATE_LIMITED_BY_YOUTUBE That error was generated by https://second.cadence.moe. Watch on YouTube → ``` Shutting down second.cadence.moe so that users stop making requests until your IP address gets unblocked might fix this in the short term. In the long term, spreading the load across multiple instances of Second and/or Invidious might prevent this from happening. Having to switch between different frontend instances creates friction for users (in the form of migrating subscriptions, preferences, etc.), but unless there is a reason CloudTube needs to be running on the same server as Second, perhaps CloudTube instances could rotate between a list of Second and/or Invidious instances as their backend to spread the load. When a Second or Invidious instance gets blocked, CloudTube instances could fallback to a non-blocked instance and avoid using the blocked instance for a certain period of time to allow it to come back online.
People can actually already manually change the backend Second or Invidious instance that the CloudTube frontend uses. Second and Invidious are almost completely compatible (you may notice small differences in number formatting, quality sorting, or missing video durations, but these can be addressed in the frontend). The instance that is used can be configured in the settings page. I plan to design a special rate limited error message page that explains the situation and directs the person to the settings page to select a new instance. I also plan to add support for anti-captcha to Second so that it can automatically unblock itself. Automatically switching instances may be possible, and I will consider this after I complete anti-captcha.
On Sat Sep 26, 2020 at 4:43 PM PDT, Cadence Ember wrote: > People can actually already manually change the backend Second or > Invidious instance that the CloudTube frontend uses. Nice! I hadn't noticed that, but it's helpful. Thanks. > I plan to design a special rate limited error message page that > explains the situation and directs the person to the settings page to > select a new instance. It might be a little smoother if from the error message page the user could select and switch to a known working instance and immediately start watching the video they were looking for using the new instance. Cadence instances could have an internal list of known Invidious and Second instances, and periodically check to see which are currently rate limited by attempting to pull the information for a test video. > I also plan to add support for anti-captcha to Second so that it can > automatically unblock itself. anti-captcha isn't automatic. It is an online CAPTCHA sweatshop that has human workers solve CAPTCHAs manually. Some users and/or instance admins may not be comfortable with this, so it would be nice to have some alternative options as well. Automatic instance switching to spread the load across instances might reduce the frequency with which instances get rate limited, and perhaps users could have the option of occasionally solving a CAPTCHA or performing some action to attempt getting an instance unblocked, similar to a script I recall being prompted to run when encountering a blocked Bibliogram instance. > Automatically switching instances may be possible, and I will consider > this after I complete anti-captcha. Thanks, and thanks for all your hard work.
Great reply. Invidious uses anti-captcha. I don't have anything else to say about the matter.
FYI, tube.cadence.moe is rate limited again. I've thought of another suggestion which may be a little less ideal than automatic instance rotation, but potentially simpler to implement: In addition to a default Second/Invidious instance, also define a fallback instance to attempt when the default instance does not work (e.g. due to rate limiting). For now a relatively reliable Invidious instance like invidious.snopyta.org might be a reasonable choice, and the user could customize their fallback instance on the settings page like they can with their default instance.
I've added what I hope is a much more descriptive notice which explains the situation and what users can do about the instance being blocked.