search

iv-org / documentation

The official Invidious documentation
https://docs.invidious.io
Creative Commons Zero v1.0 Universal
594 stars 156 forks source link

[New instance] https://invidious.nerdvpn.de #241

Closed Sommerwiesel closed 2 years ago

Sommerwiesel commented 2 years ago

URL

https://invidious.nerdvpn.de

Mandatory checks

Maintainer chart

Host country

Germany

Man in the Middle

None

Source code URL

https://github.com/Sommerwiesel/invidious

Analytics

None

Additionnal informations

Sommerwiesel commented 2 years ago

https://stats.uptimerobot.com/mn6k9upm1g

unixfox commented 2 years ago

Added on uptime robot: https://stats.uptimerobot.com/89VnzSKAn/791917306

Sommerwiesel commented 2 years ago

I have a question about the hourly restart. I understand why it's neccessary to circumvent the inevitable "invidious breaking down" after a while. However, I find it hard to believe it's the best solution to this.

Can someone explain what exactly happens when invidious crashes? Do we get any kind of status/error/log? Is there some way to monitor this and only restart invidious the moment such a crash happens?

I have full root access to my server, surely there is some better way a cronjob/monitor can watch the invidious service/website/whatever and react accordingly. I use the official docker image with a custom systemd unit starting it.

The problem I have with the hourly restart is, that it also breaks active sessions. I often watch videos which are longer than an hour and this results in the video breaking multiple times because of the restart.

Also, what if invidious breaks only 15min after the last restart, that would leave the service with a downtime of 45min until the next.

I would really like to implement a better solution that "just" a hourly restart.

Thanks for any input.

unixfox commented 2 years ago

Nowadays if you don't have use_quic enabled invidious will never really crash but it can become sluggish due to some unknown memory leaks: https://github.com/iv-org/invidious/issues/1438

This is why we recommend restarting it every hour because a public instance will receive way more traffic than a private one and will become sluggish more quickly.

If you don't want to break "active sessions", you can also run two invidious processes at the same time behind a reverse proxy and just restart one at a time. Do note that it's not normal if videojs (the player of invidious) doesn't retry if a request fails due to invidious being offline for a short period of time, you should probably open a bug report for that on invidious.

SamantazFox commented 2 years ago

Can someone explain what exactly happens when invidious crashes?

I have absolutely no clue, sorry :/ If you find out why, please open an issue with your findings !

Do we get any kind of status/error/log? Is there some way to monitor this and only restart invidious the moment such a crash happens?

I have full root access to my server, surely there is some better way a cronjob/monitor can watch the invidious service/website/whatever and react accordingly. I use the official docker image with a custom systemd unit starting it.

Nope.

The phenomenon is weird in many aspects. It's not as simple as "invidious breaks" like your program have a segfault. Invidious becomes sluggish (slow to respond) as the time goes on, and you get more occurences of weird things, like slow response times, subscriptions not refreshing anymore, database queries failing, etc..

I don't know if it's related to the language itself (maybe the internal Crystal scheduler doesn't handle that many fibers?), to one of the libraries (shards) that we're using, to the garbage compiler, or to our own code. There are so many things that I don't fully understand in the chain that could cause those problems.

As unifox said, one big source of problems was QUIC, which is a monster (it embeds its own SSL library). Since we changed the default behavior from "use it" to "not use it", it also reduced the amount of crashes encountered by users / instance admins.

I would really like to implement a better solution that "just" a hourly restart.

Thanks for any input.

I'd love to, too, but at the moment I don't have the knowledge nor the time to dig in depth in valgrind, strace, or other memory analysis tools usage.

Technically, invidious can run fine for multiple hours (generally > 6h on a medium sized instance) but in order to reduce the amount of problems (= issues) we have to handle, we decided that an 1h restart was mandatory. This indeed helped with a lot of common problems.

Until a definitive fix is found, that requirement will stay.

Sommerwiesel commented 2 years ago

Hello there, thanks a lot for the detailed answer and explaining why the whole thing isn't that simple. Huge kudos for taking your time writing this 👍🏻

As of now, I'll just accept this weird bug and keep the hourly restart active.

Have a nice week everyone :)

TheFrenchGhosty commented 2 years ago

@Sommerwiesel Instance is properly configured and has good uptime.

Please confirm that you indeed have auto-restart setup?

If yes, are you ready for it to be added to the instance list?

PS: Some, in my opinion, issues with your CSS:

If you explicitly want those "issues", it's not a problem.

Sommerwiesel commented 2 years ago

@TheFrenchGhosty Yes, please add my instance to the public list.

I confirm, I have a hourly cronjob restarting invidious active and I actively monitor the successful execution of said cronjob.

Thanks for the feedback. The "video/playlist/community" category "switcher" not being visible is a bug in the css, I will fix it asap. The rest is as intended.

A pleasure working with you guys/gals and have a nice weekend :)

FuccDucc commented 1 year ago

This instance should be removed again, due to the situation described in these links:

https://github.com/libredirect/libredirect/issues/555 https://github.com/Sommerwiesel/invidious/issues/6

I hope that Invidious takes a stance against such behavior (discrimination on the basis of country/nationality/ethnicity) I doubt that the instance would be admitted for listing should they have requested it today, with the same situation going on

// Edit: i noticed the discussion at places, like: https://github.com/iv-org/documentation/issues/149 (comments at the very bottom, including what Ammako called him bringing it up with them), and especially just https://github.com/Sommerwiesel/invidious/issues/6 after which i believe and understand what the instance operator is saying. Looks resolved to me

Sommerwiesel commented 1 year ago

Cheers, the whole thing goes a little deeper than that and I explained here what happened and why I had to take "some" measures to prevent me suddenly emptying my whole pockets for this instance... However, what I did was very wrong and it turned out to be more discriminative than actually help the situation. I apologize for the whole mess. I never wanted to discriminate. It was a heat-of-the-moment decision, which originated from me getting a warning and a huge invoice from my hosting provider.

I will never do somthing like this again i.e. block anyone out who wants to use the instance legitimately and I hope this whole mess doesn't lead to my instance getting removed.

It was a really dumb mistake for me to react like this. I'm sorry...

unixfox commented 1 year ago

@Sommerwiesel

Please double-check that you have configured hmac_key in the config file or INVIDIOUS_CONFIG then restart the instance.

You must set a random generated value for the parameter hmac_key:! On Linux, you can generate it using the command pwgen 20 1.

Sommerwiesel commented 1 year ago

Done

Sommerwiesel commented 1 year ago

Hello, I'm currently getting hit with DMCA claims and a warning from my hosting provider that they'll shut down the server. Until the issue has been dealt with, I'm forced to stop the instance.

I've already sent the DMCA template and time will show if this can get resolved in a good way. After all, I'm technically not doing anything illegal. It's just the same DMCA-bullying that plagues many YouTube channels.

Expect my instance to be down until 02-20-2023.

I will switch to a maintenance page later, but right now 502 Bad Gateway will have to suffice.

Sorry.

unixfox commented 1 year ago

Sad to see that many instances providers have been getting DMCA requests lately...

I do have plans to submitting a tutorial on how to hide your servers behind a proxy server hosted at a provider that don't care about DMCA requests or understand what invidious is.

For the time being, I'll remove your instance from the list. I hope your provider will understand that invidious is not a threat.

unixfox commented 1 year ago

Detailed comment on what will be documented related to hiding the servers: https://github.com/iv-org/documentation/issues/348

Sommerwiesel commented 1 year ago

Btw, I have not forgotten about the matrix room. Can you send me an invite?

unixfox commented 1 year ago

Please join the matrix room and ping me there: https://matrix.to/#/#invidious:matrix.org

unixfox commented 1 year ago

Hello,

We temporarily removed your instance in order to avoid the Invidious users to use an instance that doesn't work for the moment.

Once you have fixed the issue (The video returned by YouTube isn't the requested one. (WEB client) (VideoNotAvailableException)) on your instance, please ask to get your instance back in the list.

We are fully aware that this issue is not your fault, but for the moment we can't do anything than filtering in the list the instances that works from the instances that don't. Again, like said previously, we are working on the problem, and all progress will be posted in #3822.

Thank you for your understanding.

Sommerwiesel commented 1 year ago

@unixfox Please add my instance back to the public list. Ipv6 connectivity has been fixed now.

Moreover, can you add the Tor version to the list as well? jemgkaq2xibfu37hm2xojsxoi7djtwb25w6krhl63lhn52xfzgeyc2ad.onion

It's been up for almost a month now and has already been used by visitors from Russia.

Thanks :)

Sommerwiesel commented 7 months ago

@unixfox Changed my onion domain. PR: https://github.com/iv-org/documentation/pull/511

Sommerwiesel commented 7 months ago

Changed hoster from Germany to Ukraine after German hoster prooved too problematic with DMCA requests.

https://github.com/iv-org/documentation/pull/515

bugmaschine commented 7 months ago

Should be merged now