- Upgrade videojs-contrib-hls to latest version
- Update VideoJSPlayer to support "auto" quality tag to delegate to
the HLS plugin for automatic quality selection
- mediaquery change:
9f5122e031
Tampermonkey automatically requests www/js/cytube-google-drive.meta.js
to check for updates. Changed the userscript generator to write an
additional .meta.js file so that works instead of 404ing.
Previously, the user's session cookie was being checked against the
database for all non-static requests. However, this is not really
needed and wastes resources (and is slow).
For most page views (e.g. index, channel page), just parsing the value
of the cookie is sufficient:
* The cookies are already HMAC signed, so tampering with them ought to
be for all reasonable purposes, impossible.
* Assuming the worst case, all a nefarious user could manage to do is
change the text of the "Welcome, {user}" and cause a (non-functional)
ACP link to appear clientside, both of which are already possible by
using the Inspect Element tool.
For authenticated pages (currently, the ACP, and anything under
/account/), the full database check is still performed (for now).
The `cytube-common` module was created as part of a now-defunct
experiment and since then has just remained a crufty container for a few
utils. Moved the utils to the main repo and removed the dependency.
Add a dependency on `prom-client` and emit a basic latency metric for
testing purposes. Add a new configuration file for enabling/disabling
prometheus exporter and configuring the listen address.
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.
