Change explanation, courtesy of iBicha:
The \n is basically a decimal 10, which is 1010 binary. That is a field number
1, and a wire type 2 (length-delimited). Then the $ is a decimal 36, which is
exactly the length of 00000000-0000-0000-0000-000000000000.
So both objects end up being encoded into the same data.
* checking the status code returned by youtube
* add documentation link
* Update src/invidious/yt_backend/youtube_api.cr
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
This PR add an MT option to the Makefile. When make is invoked with 'MT=1',
the 'preview_mt' flag is passed to the Crystal compiler.
It doesn't mean that invidious fully supports multi-threading, but at least
it provides an easy way for trying that out.
No related issue.
Fijxu have been using it for more than 3 weeks on their instance and
they report that it works really well.
This only works if 'inv_sig_helper' itself crashes and restarts (via systemd
or docker restart policy) but it will not work if 'inv_sig_helper' hangs and
stops responding to invidious (but this is an issue with 'inv_sig_helper',
not Invidious).
Closes issue 4926
Theoretically this should improve memory usage and performance by quite a bit
as we aren't creating a new HTTP::Client and in a turn a new connection for
every image we request from YouTube.
Closes issue 4009
Use the proper URL argument when transforming youtu.be URLs to their
youtube.com equivalents.
Thanks to Tuhgy on the fediverse for reporting this!
No related issue
In Crystal, handling multi-byte sequences in UTF-8 requires understanding that
slicing by bytes can lead to invalid sequences if the slicing isn't aligned
with character boundaries. In this case, attempting to slice a string by bytes
can cut through multi-byte UTF-8 sequences, leading to invalid sequences.
To avoid this, strings should be sliced based on characters rather than bytes.
Fixes issue 4886
This PR makes it possible to display badges in the search results for third
party Invidious applications (ex: FreeTube)
See also: https://github.com/FreeTubeApp/FreeTube/pull/5590
No related issue
This PR adds the error message to the "search on Github" link located on
the crash page, so that the search bar is already filled and the issues
filtered when the user opens said link.
As seen with #4584 and other critical problems, duplicate issues end up
unnecessarily flooding the issue reports. While this change won't entirely
stop this behavior, this will help the user to easily identify if the error
they have received has been reported yet and discourage them from creating
a duplicate (hopefully...).
No associated issue was open
