Suggestion : Add option to automatically pick a random invidious instance

[DavidHenryThoreau]

I suggest to add an option wich can be disabled to automatically pick a random invidious instance (to avoid 500 error)
straw-viewer is using this option :
https://github.com/trizen/straw-viewer/blob/master/README.md#invidious-instances

[lekma]

I'm not sure it is either practical nor useful (also, I don't really like the idea of choosing an instance without the user knowing)...

[DavidHenryThoreau]

This instance may be choosen between the list used in preferences.

[memartinb]

I like the idea, though I doubt it would be usable at the moment since few of the instances seem to be working reliably. I guess one would run into errors a lot. OTOH having an option in the settings (and having it turned off by default) wouldn't hurt.

Cheerz@lekma and a big thanks for bringing yt back to kodi ❤

[DavidHenryThoreau]

I'm not sure it is either practical nor useful (also, I don't really like the idea of choosing an instance without the user knowing)...

Yeah, that's true but when some instances are overcharged, we need to go to preferences and change to another, test, and try another.. These could be automatically done by check a random instance.

[DJCrashdummy]

similar is done by Privacy Redirect: SimonBrazell/privacy-redirect#48
it uses a smaller subset of available lists (which can be edited by the user), so you don't have to change your instance every few days if something isn't working right now at your preferred one instance. ...so even users who only want to use one or very few trusted instances can just use their own very small list of servers and users who don't care stay with the default random list.
-> load balancing and failure prevention in one swoop. 😉

[SethFalco]

I think this'd be a valuable feature. However, it'd be best to implement it differently, more like what DJCrashdummy pitched with SimonBrazell/privacy-redirect#48.

If I understand this issue correctly, it load balances requests across instances by choosing a random one per action. This is nice for reducing the load on individual instances. However, not a very practical given servers are scattered across the world, so latency varies widely.

I'm also wary that there'll be issues with consistency, depending on how aggressively instances cache content. It'd be annoying if sometimes you go to a channel, the latest video is there, and other times it isn't.

Instead, I'd like to see an option available called Auto.

It'd ping each public instance, and choose one based on latency. There will be a map to back off instances if they returned errors recently. Whenever the selection takes place, it'll notify the user of what server it switched to.

For example, given the list of instances, it will use example.com:

• example.org (47 ms)
• example.com (23 ms)

If while using example.com, it runs into a timeout, forbidden, or some other error:

1. Add the instance to a map with a TTL.
2. Repeat the pings if necessary.
3. Pick the next best instance, so example.org in this case.
4. Notify the user that an error occurred, and which instance the add-on switched to.

It'd be better if it retried requests too, and switched again as necessary. This could be in a separate iteration though, having Auto without automatic retries would be a good start.

[SethFalco]

I've been working on my proposed solution, and found flaws with it.

There's no platform-agnostic way to ping hosts with Python, and it's not worth concerning over platform specifics or using a library.

To keep logic platform-agnostic, I tried doing HTTP request to the /stats endpoint of each instance to measure latency. However, the same instance can vary pretty widely, so they might as well all be overlapping. When many requests are performed, it's easy to average and determine the best server, but this approach is shoddy when comparing one-off requests.

My WIP implementation:

• SethFalco@f14a3dc

Probably best to scrap latency. So, the new proposal:

There'd be a setting called Auto-switch instances.

If enabled, we continue to use the instance the user has configured, and allows the user to reconfigure it whenever they want. Whenever an error occurs, such as a timeout, rate limit, or internal server error, we add the current instance to a backoff list for 24-hours. Meanwhile, we switch to another instance and notify the user.

Assuming the user selected an instance in a region they're happy with (privacy laws, latency, etc), we'd try to keep them in the same region. When picking a new instance, we pick one in the same region with the best health, or if there are no others in that region, just the one with the best health in general.

[lekma]

@SethFalco: I'm still not convinced it is either practical or useful...

[SethFalco]

I thought it'd be quite nice. I'll just note the use-case I had in mind, but welcome to disagree with it. 👍

Sometimes instances can be unreliable. Even the large instances like y.com.sb, vid.puffyan.us, and inv.riverside.rocks can be flaky. 🤔

A request failing occurs at least every other day, but is usually fine. It's just a retry away. However, around every 1-2 weeks, it's bad enough that I have to flip between instances, which is a chore especially when watching with others.

The recent merge with regions showing in the menu is very helpful, but it'd be better if the failures were effectively invisible, imo.

---

If that doesn't seem like a worthwhile reason, I'll shelve this and explore other avenues to improve UX.
(Is the issue is worth closing too?)

For example:

• Make is easier for users to identify the best instance for them, like the region change we did lately.
• A shortcut to the selectInstance script/action, so users can switch instance quicker. This would make it a lot less cumbersome.
• I could also try to familiarize myself more with upstream, to take a deeper look at I/O errors and performance. It's the ideal solution to this problem anyway. ^-^'