Invidious: Disable pulling content from inactive accounts to possibly improve performance

Created on 2 Oct 2019  路  4Comments  路  Source: iv-org/invidious

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;

  • If account has been inactive for X days, stop pulling new content.
  • Start pulling new content if the account is active again (user login).

How is this handled currently?

Are new content being pulled/updated 24/7 for all accounts?

Any thoughts? 馃

question

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_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:

  • A new video is received
  • A user imports their subscriptions (using /data_control)
  • A user subscribes/unsubscribes from a channel

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?

All 4 comments

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:

  • A new video is received
  • A user imports their subscriptions (using /data_control)
  • A user subscribes/unsubscribes from a channel

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_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:

* A new video is received

* A user imports their subscriptions (using `/data_control`)

* A user subscribes/unsubscribes from a channel

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?

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

apfelchips picture apfelchips  路  5Comments

Uffje picture Uffje  路  3Comments

haizrul picture haizrul  路  4Comments

dimqua picture dimqua  路  4Comments

Zero3K picture Zero3K  路  4Comments