Be aware,
Jellyfin uses semantic versioning. All releases will have versions in the X.Y.Z format, starting from 10.0.0. Note however that the 10.Y.Z release chain represents the “cleanup” of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility, at some point, with previous Emby-compatible interfaces, and may also break compatibility with previous 10.Y releases if required for later cleanup work
Yep, there even was a standard that would have been sufficient, Do Not Track. https://en.m.wikipedia.org/wiki/Do_Not_Track
I host my mail with mailcow and it is almost set and forget. I only had a couple issues with some mail providers, but a small email exchange with the admins cleared that up.
Have a handful of users, that have not complained about anything not working or spam or whatever 🤷♂️
Besides that, security by obscurity is the worst possible form and barely qualifies as security at all.
In fact security by obscurity is not security at all. In this case it should be authenticated or to the very least to actually use a random string like a uuid. But, changing the root path does prevent it from exploiting. Not perfect but a temporary solution.
It’s also another place where the Jellyfin devs leave their users to their own devices when it comes to securing the server against malicious actors.
Another place? What else? You mean setting up you own server? That is in fact your responsibility.
Lets not forget the BS when Shows are only partially available, like only Season 1-5,8-12 and so on. Not only is it expensive but also a shitty service with shitty quality and experience.
End-to-end encryption means the service provider can’t see your data even if they wanted to
Not necessarily. All it means is that intermediaries can’t see the data in transit. You need to trust that the data is handled properly at either end, and most service providers also make the apps that you run at either end.
This is incorrect. End-to-End is defined as from “User to User” and not “User to Service provider”. That would be just transport encryption.
I switched to adguard, yes. But you can just give pi-hole a dnsmasq config file. The underlying dns server Pi-Hole uses does support those.
Just mount the file via a docker volume. I will have to look up the exact paths. Config would look like
address=/domain.tld/192.168.0.1
I saw that they are working on big refactoring to use EFCore instead of doing direct SQL queries. I actually was surprised when they were saying that the migration will take days for some, and you shouldn’t interrupt it.
That you should not interrupt a database migration is really standard procedure. If it takes days is unfortunate, but what should the devs do? Create a migration process with weeks and months of testing that can recover after a interruption, for those 3 ppl that run on slow hardware?
Pls do not get me wrong, that the database and everything related to it is slow and basically legacy code is not good, but exactly that is beeing worked on right now, instead of continuously pumping out new features. Complaining about the exact thing that is currently in the works feels very disingenuous.
Based on you screenshot from the NPM Dashboard there seems to be something wrong. In the setup window you show that you forward the traffic with http and port 80, in the dashboard screenshot you forward the traffic with https and port 80.
Just skip http and self signed certificates all together. Modern Browsers make it a pain to use non https sites. A simple domain setup with dns acme challenge is a little bit of a hassle but worth the hour(s) of invested time. Especially with npm were it is a set and forget option.
Does pihole support wildcard dns entries yet? To my knowledge the gui only supports single entries so that you have to enter every subdomain manually in pihole that you want to have forwarded. Workaround would be to use a dnsmasq config file or use something else like addguard.
I know that the project is done by volunteers but I was just wondering whatever I should invest more time on trying to resolve the issues. Maybe my server specs are just not ideal for Jellyfin.
Why do you think they do not?
If you would look up what they are actually doing, you woulf realize that a lot of work is done to improve the underlying quality of code to make it easier to do major changes to core functionality. Quick and dirty fixes by the previously project, emby, has led to a very shitty code base that makes changes hard.
It usually is the directory where you execute the docker compose command.
And which one of those are actually vulnerabilities that are exploitable? First, yes ofc unauthenticated endpoints should be fixed, but with those there is no real damage to be done.
If you know the media path then you can request a playback, and if you get the user ids then you can get all users. That’s more or less it.
Good? No. But far from making it a poor choice exposing it.
If you are using arch and do not subscribe to the rss feed, then it is on you. As described here: https://wiki.archlinux.org/title/System_maintenance#Upgrading_the_system
Performance is not the goal, but cleaner code and more manageable code. But both will ultimately lead to better performance. As of now it was basically impossible to change something in the database structure since it was hard to estimate the impact of it.
… and may also break compatibility with previous 10.Y releases if required for later cleanup work.
If you read through the whole paragraph, it is clear that they mean the compatibility of previous jellyfin versions.
Also, again:
Note however that the 10.Y.Z release chain represents the “cleanup” of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,
That means that the code is not cleaned up with that release.
If you would release 11 before the code is considered cleaned up, you would basically break your own defined versioning convention. That is best decided by the active maintainers.
Consider the 10.y.z simply to be 0.y.z and everything works out.
Jellyfin inherited a lot of shitty code and architecture from emby. They simply cannot guarantee anything across patches until it is sorted out.
imho much better then releasing major version after major version because the break stuff regularly.
Also for internal use. The original emby source used not within the code base standardized database access.
Basically changes to the database were not possible since finding references across the code base which part uses which values was impossible.
Note however that the 10.Y.Z release chain represents the “cleanup” of the codebase, so it should be accepted that 10.Y.Z breaks all compatibility,
Its right there at the link you posted.
Luckily thanks to their licensing model they basically cannot. Immich has according to github as of now 1606 contributors. Changing the license so that there could even be a proprietary fork would require basically the ok by every contributor (that made a relevant code contribution)