Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129]) by mail-b.sr.ht (Postfix) with ESMTPS id BFC34FF229 for <~cadence/tube-devel@lists.sr.ht>; Sat, 26 Sep 2020 22:44:24 +0000 (UTC) Authentication-Results: mail-b.sr.ht; dkim=pass (1024-bit key) header.d=riseup.net header.i=@riseup.net header.b=KXBnUYAU Received: from bell.riseup.net (bell-pn.riseup.net [10.0.1.178]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Sectigo RSA Domain Validation Secure Server CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 4BzP3W6tgpzFd0l for <~cadence/tube-devel@lists.sr.ht>; Sat, 26 Sep 2020 15:44:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak; t=1601160264; bh=92GXT9vADOvGd73nx0ryTzzC4IOqP1ZPlYx3XucXA5Y=; h=Subject:From:To:Date:From; b=KXBnUYAUJJXbKRNRgzORhjdsAChEC1nXPNTa/IEBBJuf4zRXDdY2qU6/8sRxKNgSy barE8+iBB7F5efxNNUNtCXeA2hSWC6K129ZQdsz8FoLsB736ZAX1tUEMnrsKjIIpgp ylVx92dwJ7/KvZxBKKdbp+O5em5zSbloL1e8gbNc= X-Riseup-User-ID: 7A62F0F25572DCCD3B26F4C31AC5A0717F40D164083887832FC967D4A4CD7099 Received: from [127.0.0.1] (localhost [127.0.0.1]) by bell.riseup.net (Postfix) with ESMTPSA id 4BzP3W5M0nzJqPK for <~cadence/tube-devel@lists.sr.ht>; Sat, 26 Sep 2020 15:44:23 -0700 (PDT) Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Subject: YouTube rate limiting From: "Mason Hock" To: <~cadence/tube-devel@lists.sr.ht> Date: Wed, 23 Sep 2020 15:39:42 -0700 Message-Id: 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 =E2=86=92 ``` 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.