Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Waiting to run
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
* doc: Update HTTP proxy configuration comments
Added information about proxy configuration for YouTube streams.
* Document supported proxy types in config.example.yml
Added note about supported proxy types in configuration.
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
* Remove signature helper completely from Invidious
The official way to reproduce video with Invidious now is by using
Invidious Companion which uses Youtube.JS with a Javascript Interpreter
that can successfully decrypt youtube video URLs.
Sig helper has not been used for a long time, is beyond broken and no
one has plans to fix it and maintain it.
* Remove DECRYPT_FUNCTION and shrink player function
* remove `sp = cfr[sp]`
* Improve message
Video information from youtube always weight about ~60KB uncompressed.
When using Deflate to compress that information, it gets compressed down
to ~15KB, so now you will be able to store up to 4x entries more with
caching enabled.
For context, nadeko.net Invidious instance stores 54.7k keys, since we
also store the `time` in a different key associated to the video ID, the
real count of videos cached would be 27.3k. With compression enabled,
the Redis database will be able to store up to 4 times more videos in
cache, which is 109.2k videos cached.
Pretty cool huh.
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
Build and release container directly from master / release (docker/Dockerfile.arm64, ARM64, ubuntu-24.04-arm, linux/arm64/v8, -arm64) (push) Has been cancelled
This commit adds a new configuration option `max_request_line_size` that allows
users to increase the HTTP request line size limit. This is particularly useful
for handling very long continuation tokens that can cause 414 (URI Too Long) errors.
Changes:
- Add `max_request_line_size` property to Config class
- Configure Kemal server to use the custom limit if specified
- Document the option in config.example.yml with recommendations
- Add examples in docker-compose.yml for both YAML and env var configuration
The default behavior remains unchanged (8KB limit) unless explicitly configured.
This provides a solution for users experiencing 414 errors without affecting
existing installations.
Unless an instance maintainer was using the `database_url` attribute,
and knew about the connection pool query parameters, the database
connection pool settings was relegated to the default settings...
And the default settings are... not great for any large instance. With it
essentially only allowing a single connection within the pool, a maximum
checkout time of a 5 seconds, and basically no additional retries whatsoever
its no wonder that PgBouncer has became a staple among Invidious instances.
This PR changes that by exposing the ability to configure the database
connection pool that is used within the library that Invidious uses to
interact with Postgres.
https://github.com/jgaskins/redis
It's faster and in active development, old one gave me this using a TCP
connection:
test 5.94k (168.34µs) (±56.73%) 144B/op fastest
test 5.11k (195.76µs) (±58.89%) 144B/op fastest
test 5.48k (182.33µs) (±73.39%) 144B/op fastest
test 3.42k (292.56µs) (±66.19%) 144B/op fastest
meanwhile, the jgaskins/redis one gives:
test 6.96k (143.66µs) (±58.73%) 96.0B/op fastest
test 6.36k (157.16µs) (±55.95%) 96.0B/op fastest
test 7.06k (141.65µs) (±57.03%) 96.0B/op fastest
* add support for invidious companion
* redirect latest_version and dash manifest to invidious companion
* fix Shadowing outer local variable `response`
* fixing condition for Content-Security-Policy
* throw error if inv_sig_helper and invidious_companion used same time
* Use sample instead of Random.rand
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
* Remove debug puts functions
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
* modify the description for config.example.yaml about invidious companion
* move config checks for invidious companion
* separate invidious_companion logic + better config.yaml config
* fixing "end" misplacement
* fix linting + use .empty?
* crystal handle decompression already by itself
* fix download function when invidious companion used
* fix linting
* invidious companion always used so always add CSP and redirect latest_version
* apply all the suggestions + rework invidious_companion parameter
* format watch.cr
* fix ameba Redundant use of `Object#to_s` in interpolation
* add ability for invidious companion to check request from invidious
* Better document private_url and public_url
* Better doc for invidious_companion_key
* !empty? to present?
* skip proxy for invidious companion
* fixing format
* missing ,
* add companion pooling http
* fix: don't use http proxy when sending requests to companion
* fix: logic where we want to have the invidious logic if companion is not used
* chore: remove baseurl usage from invidious companion
* chore: change from inv-sig-helper to companion for required playback
* fix: use puts + add warning for inv-sig-helper deprecated
---------
Co-authored-by: syeopite <70992037+syeopite@users.noreply.github.com>
This PR adds a configuration option to control the preloading of video data on
page load with the HTML5 'preload'[1] attribute on the `<video>` element.
The option is enabled by default, meaning that the `preload` attribute's value
will be 'auto'. If users want to prevent preloading of video data, they
can disable the option, which will set the attribute value to 'none'.
[1](https://www.w3schools.com/tags/att_video_preload.asp)
Closes issue 4110
