[New instance] https://invidious.materialio.us

WardPearce commented 4 months ago

URL

https://invidious.materialio.us

Mandatory checks

[X] Instance has a domain name
[X] Instance is served over HTTPS
[X] Statistics (/api/v1/stats) are enabled
[X] Instance is properly configured (including the mandatory post install configuration)
[X] Instance has an automatic hourly restart setup of Invidious
[X] If dash, proxy + download is enabled (default settings), the instance has unlimited traffic/bandwidth or close to unlimited (100TB minimum)
[X] Instance is not running any kind of analytics

Maintainer chart

[X] Ensure that my instance is up to date (less than one month old)
[X] Ensure a proper uptime of my instance (around 90%)

Host country

New Zealand

Man in the Middle

No response

Source code URL

https://github.com/WardPearce/Materialious

Additional information

By default we want users using https://materialio.us (Using the Materialious frontend), so could that be the listed instance?

Our Invidious frontend is hosted at https://invidious.materialio.us, this can also be included in the list of instances & should be used for tracking the uptime of our instance.

github-actions[bot] commented 4 months ago

Hello! Your instance has been added to our monitoring system: https://updown.io/y6zr You need to wait 30 days before we add your instance, this is to evaluate that your instance will keep a good uptime for one month.

Make sure you double checked all the mandatory checks or this will slow down the process of adding your instance!

Please consult these two important tutorials:

Escaping the YouTube block (403 errors in playback): https://docs.invidious.io/ipv6-rotator/
Improving the performance and the stability of your public instance: https://docs.invidious.io/improve-public-instance/

It is highly recommended to follow these tutorials because it will allow the instance to stay stable and performant over the long term.

Please consider joining the Matrix room for public instance maintainers by joining our Matrix room: https://matrix.to/#/#invidious:matrix.org then pinging @ unixfox, @ TheFrenchGhosty and @ SamantazFox for asking to be invited to the Matrix room. We discuss troubles managing a public instance, sharing some advices and more.

unixfox commented 4 months ago

We only list instances that are running the invidious software for the frontend.

Only https://invidious.materialio.us is a candidate.

WardPearce commented 4 months ago

We only list instances that are running the invidious software for the frontend.

Only https://invidious.materialio.us is a candidate.

Okay sounds good 👍

WardPearce commented 4 months ago

@unixfox for some reason it appears to be pinging materialio.us not invidious.materialio.us, even tho thats the instance I provided under "URL". So the current uptime tracking isn't accurate.

perennialtech commented 3 months ago

@WardPearce Thanks for submitting your instance. While you wait for the 30 day monitoring for uptime, please double-check the following:

Your instance appears to be setting the Server header twice in its responses, once with Caddy and once with nginx/1.25.5. This suggests a misconfiguration in your reverse proxy setup. Please review and correct your reverse proxy configuration to ensure the Server header is only set once with the correct value.
As mentioned by the GitHub bot, ensure that you have completed the following tutorials from the Invidious documentation:
- Rotate your IPv6 address for escaping YouTube blocking
- Improving your public instance performance and stability

I've also added https://invidious.materialio.us to monitoring at updown.io. However, this will mean that you will need to wait an additional two weeks to complete the required 30-day uptime check. Sorry about the delay here.

WardPearce commented 3 months ago

@WardPearce Thanks for submitting your instance. While you wait for the 30 day monitoring for uptime, please double-check the following:
* Your instance appears to be setting the [`Server`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Server) header twice in its responses, once with `Caddy` and once with `nginx/1.25.5`. This suggests a misconfiguration in your reverse proxy setup.
  Please review and correct your reverse proxy configuration to ensure the `Server` header is only set once with the correct value.

* As mentioned by the GitHub bot, ensure that you have completed the following tutorials from the Invidious documentation:

  * [Rotate your IPv6 address for escaping YouTube blocking](https://docs.invidious.io/ipv6-rotator/)
  * [Improving your public instance performance and stability](https://docs.invidious.io/improve-public-instance/)
I've also added https://invidious.materialio.us to monitoring at updown.io. However, this will mean that you will need to wait an additional two weeks to complete the required 30-day uptime check. Sorry about the delay here.

Fixed the server header, Yes my instance is rotating IPV6 addresses twice a day & I've followed the best practices for improving performance and stability (currently running Invidious on 6 threads).

Thank you

Also I'm tracking uptime myself here https://status.wardpearce.com/status/foss under "Materialio.us" (just in case)

Also might be of note, that my instance is modifying response headers as the following

access-control-allow-credentials
    true
access-control-allow-headers
    User-Agent,Authorization,Content-Type
access-control-allow-methods
    GET,POST,OPTIONS,HEAD,PATCH,PUT,DELETE
access-control-allow-origin
    https://materialio.us/

WardPearce commented 2 weeks ago

Greetings, I've recently had to move house very suddenly. At this new house it appears my ISP hasn't enabled IPv6, thought I should alert you guys as this will result in a prolong downage of my instance. I've reached out to my ISP recently and hopefully will have the matter sorted soon.

WardPearce commented 1 week ago

Greetings, I've recently had to move house very suddenly. At this new house it appears my ISP hasn't enabled IPv6, thought I should alert you guys as this will result in a prolong downage of my instance. I've reached out to my ISP recently and hopefully will have the matter sorted soon.

I've resolved this & my instance should be back up & working.

iv-org / documentation