This reverts commit 0f9bc44925.
The original commit was not backwards compatible with use cases that
users were relying on, such as emotes being sorted in insertion order by
default.
I will develop a new patch which fixes the performance issue in a
backwards compatible way.
Unfortunately I think this is just one of a whole class of race
conditions caused by errored channels being unloaded immediately without
waiting for the refcounter to reach 0.
However, this one is the only one that appears commonly in the logs so
adding this check should buy time to rethink the overall problem.
Browsers which don't support CyTube's limited subset of
generally-supported codecs probably aren't worth warning about.
1Mbps is way too low of a threshold to warn about bandwidth, but even if
the threshold for warning were raised, it's probably still not that
useful.
The use of the channel library as a cache for metadata to avoid
re-requesting metadata for known media is an optimization that dates
back to 1.0. However, it doesn't have any TTL, is prone to bugs, and is
of dubious value.
This commit ignores the results of the library check when queueing a new
video, opting to always re-request the metadata. This fixes a few bugs:
* Google Drive metadata being lost when storing in library
* Streamable metadata being lost when storing in library
* Videos in the channel library that are now unavailable on their
source website being queueable and then failing to play (e.g. deleted
YouTube videos).
In its place, a small fail-open check is left behind to emit metric
counters on how many queues would have been cache-hits, to provide
insight into whether a proper caching solution (i.e. one not tacked on
top of the library) would be worth pursuing or not. This will be
removed eventually.
Fixes#681. Technically, resending the entire userlist is not
necessary; it would be sufficient to resent setUserMeta, but there's not
currently a bulk frame for that so sending the userlist is probably more
efficient.
Camo: https://github.com/atmos/camo. This has a couple advantages over
just allowing images to be dumped as-is:
- Prevents mixed-content warnings by allowing the server to proxy HTTP
images to an HTTPS camo instance
- Protects users' privacy by not exposing their browser directly to
the image host
- Allows the camo proxy to intercept and reject bad image sources
(URLs that are not actually images, gigapixel-sized images likely to
DoS users' browsers, etc.)
Whitelisting specific domains is supported for cases where the source is
known to be trustworthy.
