The current option to export subscriptions for NewPipe (`Export subscriptions as OPML (for NewPipe & FreeTube)`) isn't accepted by NewPipe anymore. As far as I can tell, NewPipe only accepts importing from its own SQLite database, from Google Account CSV export and from its own JSON export format. This is mentioned in https://github.com/iv-org/invidious/issues/5438.
This PR adds support to export subscriptions in the NewPipe compatible format. I'm looking for input on a few points:
- I'm not a huge fan of hardcoding the NewPipe version in the export, but it is required by NewPipe to recognize it as a valid file. If someone has a better idea I'm all ears but I think it's the only way. In any case, NewPipe can import formats in a backwards compatible way in the future so it shouldn't be a huge deal.
- I haven't checked if the OPML export option actually works for FreeTube. If it doesn't, it should probably be removed altogether, for now I just removed the `(for NewPipe)` part.
- The translations would need to be updated, but I don't know how that is handled in this project so I need some help there.
The new format looks like this:
```
{
"subscriptions": [
{
"service_id": 0,
"url": "https://www.youtube.com/channel/UCHnyfMqiRRG1u-2MsSQLbXA",
"name": "Veritasium"
},
{
"service_id": 0,
"url": "https://www.youtube.com/channel/UC6nSFpj9HTCZ5t-N3Rm3-HA",
"name": "Vsauce"
}
],
"app_version": "0.29.0",
"app_version_int": 1014
}
```
* add subscription json export for NewPipe
* remove old newpipe export format
* make newpipe export values constant
* remove duplicate export option, add i18n keys
* Convert to_newpipe to a serializable struct
* Use same naming format as NewPipe for the exported subscriptions
---------
Co-authored-by: Fijxu <fijxu@nadeko.net>
* feat(channel): add support for shows tab
* feat: add support for /show/ urls
* chore(docs): add comment for GridShowRenderer and fix format
* fix: check that shows tabs exists before trying to fetch/parse
* fix: Remove `thumbnaiext`
This property doesn't exist.
Not exactly sure how it happened but I'm guessing I combined thumbnailOverlays and text somehow when I was doing a find and replace (Ctrl + H) and then formatting json with prettier
* chore: Completely remove Reddit from Invidious
* chore: remove reddit from config.example.yml
* fix comment preferences for nojs
* Add fallback for people that used reddit in the comments API and their preferences
* add missing TODO
* chore: remove unused swap_comments JS function from watch.js
* remove blank line
* 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.
