Jellyfin does not handle NAT punching automatically to point that a non technical user can install an app on their TV, see one or more libraries, and connect to my server across the Internet. This is the biggest problem that Plex solves compared to Jellyfin. I can’t expect my parents to install Tailscale or make any changes to their network.

That being said I use Jellyfin. I just don’t share it with my friends.

Does it support Health Connect so I could import from other services or just Google Health? I’ve used Samsung Health for long time and want to move to something open.

15.0 adds support for OIDC tokens being handed to Actions workflows compatible with GitHub Actions. I was excited to upgrade because I wanted to continue doing cosign Docker image signing, but then I found out that the Cosign transparency log doesn’t support Forgejo. Looks like I need an alternative.

My next biggest problem is the Actions workflow itself. I setup Docker in Docker, but turns out there’s a bit of work in preparing the runners to be on par with what I used on GitHub.

Otherwise, I’ve found Forgejo to be quite good and almost all my private repos are moved over.

I use it to play music from Jellyfin to my Sonos speakers. It won’t fix a Jellyfin library that has bad data, but it can pull in music from multiple different sources and push to different players.

It works well enough. Some issues where songs get interrupted, but I think that’s issue with the Music Assistant/Sonos integration.

If the app is just a WebView wrapper around the application, then the challenge page would load and try to be evaluated.

If it’s a native Android/iOS app, then it probably wouldn’t work because the app would try to make HTTP API calls and get back something unexpected.

Unless you’re running VLANs, in which case the inter VLAN is normally handled by the router. I also expose my home lab services over BGP so all my traffic hits the router then comes back to my lab services.

https://forum.syncthing.net/t/discontinuing-syncthing-android/23002

According to this post, it was partly that and lack of maintainers. Given there’s maintainers for a fork, I’m curious why they didn’t bring them into the main project.

Reason is a combination of Google making Play publishing something between hard and impossible and no active maintenance. The app saw no significant development for a long time and without Play releases I do no longer see enough benefit and/or have enough motivation to keep up the ongoing maintenance an app requires even without doing much, if any, changes.

We’re sort of in this situation because the official project decided not to continue providing an official Android app, yet people want to use it on Android forcing unofficial versions to be created and maintained.

I get that they don’t want to deal with Google Play anymore, but somebody has to deal with it and them not owning the app is putting users at risk.

How would that work? The use case is for previews for pull requests. Somebody submits a change to the website. This creates a preview domain that reviewers and authors can see their proposed changes in a clean environment.

CloudFlare pages gives this behavior out of the box.

It is for pull requests. A user makes a change to the documentation, they want to be able to see the changes on a web page.

If you don’t have them on the open web, developers and pull request authors can’t see the previews.

The issue they had was being marked as phishing, not the SSL certificate warning page.

Small correction. He was impeached by the House. The Senate then decides whether to convict, not whether to impeach.

A newer release, v0.6.30 is already released to fix an issue with OneDrive integration.

Looks like they finally finally made their slim image tag smaller than the main image:

ghcr.io/open-webui/open-webui:v0.6.30-slim    7c61b17433e8   46 hours ago    4.3GB
ghcr.io/open-webui/open-webui:v0.6.30         c1ac444c0471   46 hours ago    4.82GB

Though only saving .5GB of space is not very slim. I use OpenWebUI in my home lab, but this issue just made me question the quality of the project a tiny bit.

I’ve been running my own mail for 10+ years. I recommend rspamd for spam filtering. It took the place of SpamAssasin, grey listing, SPF checking, etc. All in one single system.

How do you expect the packets to actually route? If you run Tailscale and your VPN on your phone, they might fight with each other for control of the routing table.

If you’re trying to use Tailscale exit note to then route through Tailscale to one node running gluetun to Mullvad. That’s going to be complex because against they both want to mess with the routing table.

Tailscale natively supports Mullvad: https://tailscale.com/mullvad

Okay it was a little hard to read since your post was missing formatting. TS_SUBNETS is what controls what CIDRs are announced through Tailscale. Since you’re not using Docker networking for Jellyfin, it would be whatever subnet the host is on. Maybe it’s 192.168.x.y

Gluetun doesn’t make any sense here. You’re forcing all the traffic for from Jellyfin to go through Mullvad, but you need to be able to connect to Jellyfin because Jellyfin is a service you connect to.

Since your Tailscale is host network mounted, you’ll be able to expose your Docker network subnets over Tailscale then access Jellyfin. This is done via the TS_SUBNETS env variable. Docker will use a 172.16.0.0/12 subnet.

You probably intend to gluetun your downloading software, not Jellyfin.

https://aidarwinawards.org/nominees/taco-bell-ai-drive-thru.html

Your options are to run smaller models or wait. llama3.2:3b fits on my 1080 Ti VRAM and is sufficiently fast. Bigger models will get split between VRAM and RAM and run slower but it’ll work.

Not all models are Gen AI style LLMs. I run GPU based speech to text models on my GPU too for my smart home.

I don’t think there is a technical issue or any kind of complexity at issue here, the problem seems trivial even though I haven’t worked the details. It is moot since it’s broken on purpose to preserve “They’s” business model.

I’m explaining what the technical problems are with your idea. It seems like you don’t fully understand the technical details of these networking protocols and that’s okay but I’ve summarized a few non trivial technical problems that aren’t just people keeping multicast from being used. I assure you if multicast worked, big tech would want to use it. For example, Netflix would want to use it to distribute content to their CDN boxes and save tons of bandwidth.

I don’t know who they is in the case, but let’s think about this for a minute.

Technically what do you need for this to work?

How many Multicast Addresses do you need? How are multicast addresses assigned? Can anybody write to any multicast address? How do I decide that 239.53.244.53 is for my file not your movie? How do we know who is listening? This is effectively BGP, but more tricky because depending on the answer to the previous question you may not benefit from any network block sizes to reduce the routing info being shared. How do you decide when to start transmitting a file? Is anybody listening? Does anybody care?

You seem latched on to assume that technically would work and haven’t asked if it is actually technically a good solution. P2P is going to work better than multicast