We have quite a budget collected over the last 5 years, and while we're really happy to see so many in the Jellyfin community contribute to us, we want to ask you to stop! No, really. We don't actually need your money. At least, not here an...
We have quite a budget collected over the last 5 years, and while we're really happy to see so many in the Jellyfin community contribute to us, we want to ask you to stop!
No, really. We don't actually need your money. At least, not here and now.
We have over $24,000 in the bank, and with average monthly expenses of only ~$600, that's over 40 months (3.3 years) of runway! So, we have plenty of money for the near future.
Thus, at this time, we want you to seriously consider donating to the authors of Clients you use, instead of (or in addition to) the main project. Client support is the hardest part of the Jellyfin ecosystem to keep going, and most of them are maintained by only a single person or very small team. With the API changes in 10.9.0 and the upcoming 10.10.0 releases, they're going to be very busy trying to keep up, and thus could really use your support in a way that the core project here doesn't right now.
So, if there's a client you use every day and that you love, consider finding it's author in our list of official clients, and sending them a little something instead (or too).
No, this doesn't violate our policy of "no paid development", because donations are just that - donations. We will still not honour bug bounties or similar, and still not use our collective finance here for paid development. So don't feel like you're doing something wrong, you're not!
I'll leave this notice up until we drop to ~1 year (12 months) of remaining runway, at which time we can re-evaluate where we're at.
Happy watching!
I personally would rather see then take some of the "extra" money and apportion it to suitable client projects themselves, but I can understand them not wanting to become financial administrators in that way.
Time and time again, media will be removed from public viewing for nearly any reason. Online streaming services have what you want to watch only so long as their license to it is valid. Once it expires, it's gone off that platform - and not always to another one. Or the media gets edited to remove or alter something the owners don't want to promote.
This is even true for the varying methods of sailing. Not everything will be available indefinitely. Certainly not at zero effort. While not being as simple as signing up for a service and watching a low bitrate copy of something within thirty seconds, it's not rocket science. You can get Jellyfin running with a small library in half an hour.
Ultimately, do what suits you. A local media server works for some. Others will have everything in a single folder and view it through VLC. It's pretty irrelevant though when the vast majority just pay a subscription to one or multiple of the streaming companies that continue to serve watered down libraries at ever increasing prices.
I don't know what you are talking about. I have never been unable to access whatever media I wanted using nothing but a web browser for the last 20 years.
The last problem I can remember having is not being able to see season 2 of interview with a vampire on streamio because of some weird glitch. So I opened a browser and played it in like 15 seconds just by googling what I wanted to watch and Free TV.
I think I explained what I was talking about rather well. Trying to view a piece of media in its highest release format isn't something that's always feasible. Anything even a few years old can to difficult to source. Ask anyone rebuilding a library after a drive failure. It's even worse if what you're trying to get had low viewership - it means an even smaller pool of people bothering to host the data.
While I'm sure this is a niche situation within a niche situation, hosting your own media library locally allows offline playback. Quite nice in during a thunderstorm. Not an option with what you've described as your methods, but again, definitely an uncommon use case.