Upstream has no way to tell a Short from a long-form upload in a feed:
`ChannelVideo#to_json` reports `"type": "shortVideo"` for every row, and
`channel_videos.length_seconds` is 0 for anything absent from the channel's
Videos tab — Shorts and stream VODs alike. 531 of 1586 rows (34%) were in
that state.
YouTube's per-channel uploads playlists supply the signal, addressed by
replacing the "UC" of the channel ID: UULF long-form, UUSH Shorts, UULV live.
Measured over 75 channels, 15 newest entries each: 1114 long-form, 679 Shorts,
299 live, one Short leaking into a UULF feed.
ClassifyChannelVideosJob labels `kind` from those feeds, falling back to a
capped `HEAD /shorts/<id>` probe (200 = Short, 303 = not) for rows older than
a 15-entry window. `feed_kinds` restricts the subscription feed via a
predicate in each user's materialized view.
A separate job rather than an edit to `fetch_channel`, and `kind` is absent
from the insert's `ON CONFLICT DO UPDATE` set, so a channel refresh cannot
overwrite a label. Unclassified entries are always shown and an empty
`feed_kinds` admits everything, so the feed cannot end up blank.
Also folds in three pre-existing ameba Performance/ChainedCallWithNoBang
fixes in arik_settings.cr and admin_settings.cr, which a newer ameba release
started flagging.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
/admin/settings, linked from the administrator section of the
preferences page and refused to everybody else, edits the settings the
fork added: the playlists behind the Popular and Trending feeds, and the
whole trusted-header block.
- The playlists are picked from the instance's public playlists with a
tick box each and a number beside it for the position, so no ordering
has to be typed. A text area takes IDs that are not local playlists.
Unticking everything restores the stock feed for that feed.
- A playlist that is missing or not public is reported as a warning and
still saved: the feed skips it the same way, and an admin may be
listing a playlist they are about to create.
- The trusted-header block is refused whole when anything in it is
wrong, so a half-applied block can never reach the running config. A
CIDR range and an empty proxy list with the feature on are the two the
page exists to catch.
- A save writes the rows and applies the values to the running CONFIG,
so it needs no restart, and it survives one.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Add error message when comments are disabled
* Add btn to try reddit comments when yt is disabled
* Escape warning messages for disabled comments
* Add missing semicolons
* Update comment detection to not use msg renderer
* Use short syntax for comment entry-point detection
Co-authored-by: Samantaz Fox <coding@samantaz.fr>
* Condense try-reddit-comments-link HTML in player.js
Co-authored-by: Samantaz Fox <coding@samantaz.fr>
* Improve locale keys for comments disabled messages
Co-authored-by: Samantaz Fox <coding@samantaz.fr>
* Remove extra whitespace
* Use button instead of anchor for try reddit link
* Request Reddit comm when yt disabled during nojs=1
* Change order of commentsEnabled in parse results
* Lint
* Rebase error
* update the naming of the comments section in Innertube
Downstreamed from 36ac67610d
---------
Co-authored-by: Samantaz Fox <coding@samantaz.fr>
Co-authored-by: Fijxu <fijxu@nadeko.net>
* fix: restore dmca_content functionality
This restores (or adds) the functionality of the `dmca_content` config
option that at this date, has been unused and makes no effect.
* only disable download widget for dmca video ids
textcaptcha.com seems to be down since April and it does not appear that
service will be restored.
Text captchas can be easily automated using free LLMs, so keeping the
text captcha is more like a gate to create accounts in mass on public
Invidious instances.
It also gives headaches like bots automating account creation to modify
the videos that appear popular page of each instance (since the popular
page is based on the subscriptions of the registered users).
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
Fix#4110 by adding an option to control the preloading of video data on
page load. If disabled ("false"), the browser will not preload any video
data until the user explicitly hits the "Play" button.
If enabled ("true"), the default behavior will be used, which means the
browser decides how much of the video will be preloaded.
