* Fix 0 view count on related videos
* Remove view_count variable since it's unused by Innertube
* Remove view_count from specs and API
---------
Co-authored-by: Fijxu <fijxu@nadeko.net>
* 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 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.
Of the technically four fibers spawned by `create_notification_stream`
two of them are wrapped around an ensure clause to always unsubscribe
itself from the notification job after an error, or when it simply
finishes.
The first is the heartbeat fiber, which is also actually the main
fiber of the route handler. The second is a fiber that awaits for
notification pushes from the notification job through the
`connection` channel. When an error occurs within the main heartbeat
fiber, the ensure clause is executed and the function will unsubscribe
itself from receiving any pushes from the notification job.
The problem however is that this could (will almost always actually)
occur when the notification receiver fiber is awaiting a value from
the notification job. Except the job will no longer be able to
send anything to the receiver since they were unsubscribed by the
heartbeat fiber just a moment ago.
The notification receiver fiber will now block indefinitely.
And in doing so will pretty much prevent the entire execution stack of
the fiber and the `create_notification_stream` function from getting
garbage collected.
The IO buffers for the contents of the request and
response will stay referenced, the underlying TCP/TLS sockets will
become inaccessible and leaked, the parsed structures of the YT's
massive JSON objects will stay allocated, etc.
This PR simply merges the two into a single fiber, via a select
statement ensuring that there will be no concurrency problems.
