Would it be a good idea to not pull any new content for inactive accounts, to possibly improve performance, or lessen the server load at least?
Something like;
How is this handled currently?
Are new content being pulled/updated 24/7 for all accounts?
Any thoughts? 馃
if you check if the account is active again then you are already pulling
The process for updating subscriptions happens in two steps: It pulls content from all tracked channels, and then "compiles" a subscription feed when there is new content (determined by feed_threads in the config).
A tracked channel is a channel that at least one user has subscribed to at one point in time. It's possible for a channel to be tracked but have no subscribers (if all users on an instance have unsubscribed). There's some optimization possible here, currently I don't think it's worth the added complexity.
Otherwise, I don't see much room for optimization in the first step. Content can be sent directly to the instance (if use_pubsub_feeds is enabled) which IMO is currently the best optimization possible.
As mentioned above, content is pulled _per channel_, rather than _per user_, so the optimization being suggested doesn't make much sense to me.
A user's feed is queued to be refreshed when:
/data_control)It may be possible to defer refreshing a user's feed if that user hasn't logged in for some x days/months threshold. I'm very wary of that optimization though since currently there isn't a good way of determining when a user is inactive.
What does the config.yml look like for your instance?
maybe there is room for optimization if multiple instances work together and each one pulls a portion of the channels
The process for updating subscriptions happens in two steps: It pulls content from all tracked channels, and then "compiles" a subscription feed when there is new content (determined by
feed_threadsin the config).A tracked channel is a channel that at least one user has subscribed to at one point in time. It's possible for a channel to be tracked but have no subscribers (if all users on an instance have unsubscribed). There's some optimization possible here, currently I don't think it's worth the added complexity.
Otherwise, I don't see much room for optimization in the first step. Content can be sent directly to the instance (if
use_pubsub_feedsis enabled) which IMO is currently the best optimization possible.As mentioned above, content is pulled _per channel_, rather than _per user_, so the optimization being suggested doesn't make much sense to me.
A user's feed is queued to be refreshed when:
* A new video is received * A user imports their subscriptions (using `/data_control`) * A user subscribes/unsubscribes from a channelIt may be possible to defer refreshing a user's feed if that user hasn't logged in for some
x days/monthsthreshold. I'm very wary of that optimization though since currently there isn't a good way of determining when a user is inactive.What does the
config.ymllook like for your instance?
Understand. It was just a thought, that is was unnecessary to update feeds if the user was inactive.
Currently there's 143 'activeMonth' out of 486 'total', so 343 users haven't been active within the last month, which could potentially be a lot of unnecessary data being updated, of course depending on how many channels each user is subscribed to.
In your case, the potential could be major.
Here's my config.yml:
---
channel_threads: 1
feed_threads: 1
db:
user: kemal
password: xxxxxxxx
host: xxxxxx
port: 5432
dbname: invidious
full_refresh: false
https_only: true
hmac_key: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
domain: xxxxxx.xx
use_pubsub_feeds: false
default_home: Trending
feed_menu:
- Trending
- Popular
- Subscriptions
top_enabled: false
captcha_enabled: true
login_enabled: true
registration_enabled: true
statistics_enabled: true
admins:
- xxxxx
port: 3000
external_port: 443
host_binding: xx.xx.xx.xx
default_user_preferences:
annotations: false
annotations_subscribed: false
autoplay: false
captions:
-
-
-
comments:
- youtube
-
continue: false
continue_autoplay: true
dark_mode: false
latest_only: false
listen: false
local: false
locale: en-US
max_results: 40
notifications_only: false
player_style: invidious
quality: hd720
redirect_feed: false
related_videos: true
sort: published
speed: 1.0
thin_mode: false
unseen_only: false
video_loop: false
volume: 100
dmca_content: []
check_tables: true
cache_annotations: false
hsts: false
disable_proxy: true
force_resolve: ipv4
*Edit
Thanks for the thorough answer!
Most helpful comment
The process for updating subscriptions happens in two steps: It pulls content from all tracked channels, and then "compiles" a subscription feed when there is new content (determined by
feed_threadsin the config).A tracked channel is a channel that at least one user has subscribed to at one point in time. It's possible for a channel to be tracked but have no subscribers (if all users on an instance have unsubscribed). There's some optimization possible here, currently I don't think it's worth the added complexity.
Otherwise, I don't see much room for optimization in the first step. Content can be sent directly to the instance (if
use_pubsub_feedsis enabled) which IMO is currently the best optimization possible.As mentioned above, content is pulled _per channel_, rather than _per user_, so the optimization being suggested doesn't make much sense to me.
A user's feed is queued to be refreshed when:
/data_control)It may be possible to defer refreshing a user's feed if that user hasn't logged in for some
x days/monthsthreshold. I'm very wary of that optimization though since currently there isn't a good way of determining when a user is inactive.What does the
config.ymllook like for your instance?