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.
- 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
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.
Allows switching resolutions via the video.js UI. Also added support on
the player side for 540p, 1440p, and 2160p videos, although the metadata
extractors have not been updated to provide these sources yet.
We now allow server operators to customize the /r/ part of the channel links
The new config option in the template is commented and the config module validates and will terminate with status 78 if an improper value is used.
We've also dropped some old cruft and uses a more elegant method to assign CHANNEL.name
Resolves#668
