* Prevent player microformat from being overwritten by the next microformat
Closes https://github.com/iv-org/invidious/issues/5443
The player microformat is what we need to get the published date,
premiere timestamp, allowed regions and more information of the video.
Youtube introduced a new `microformat.microformatDataRenderer` in the
next endpoint which overwrote the player microformat
`microformat.playerMicroformatRenderer` when merged
* Update src/invidious/videos/parser.cr
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
This changes its behavior to align with the stdlib variant in that
compression is now delayed till the moment that the server begins to
send a response.
This allows the handler to avoid compressing empty responses,and
safeguards against any double compression of content that may occur
if another handler decides to compressi ts response.
This does however come at the drawback(?) of it now removing
`content-length` headers on requests if it exists; since compression
makes the value inaccurate anyway.
See: https://github.com/crystal-lang/crystal/pull/9625
The original approach cannot be used to properly handle the precedence
of `popular_enabled` in relations to the new `pages_enabled` since it
is impossible to determine whether they are unset due to the presence
of default values.
In addition the original precedence handling wasn't actually doing
anything since PagesEnabled.has_key? will always return true if the key
is valid and thus use page_enabled and its default values regardless of
whether popular_enabled was set or not (which again is also impossible
to know)
To fix this two new instance variables are introduced in order to track
whether these two attributes were present in the YAML config and the
logic for handling them is instead reduced to only using `page_enabled`
and copying `popular_enabled` to page_enabled["popular"] when
`page_enabled` field is unset.
The exception handling for database connections results in an
`ex` variable which Ameba sees as overshadowing the `ex` used by the
`ex` block arg used to define the HTTP status code 500 handler below.
Although this is a non-issue since the db connection exception handling
will cause Invidious to exit, Ameba's nature as a static checker means
that it isn't aware of this.
The simplest fix without a dirty ameba ignore comment is to rename `ex`
within the Kemal handler block below, since `ex` within a begin rescue
block is a Crystal convention that will also cause Ameba to raise when
not adhered to.
`update_ticker_count` used to use STORAGE_KEY_STREAM to get the number of notifications which is a boolean value, now it uses STORAGE_KEY_NOTIF_COUNT which is an integer
