Live data from Hacker News

A Call for Developers – Jellyfin

jellyfin.org

91–100 of 127 posts

Re: A Call for Developers – Jellyfin

#91
I just took a look at their GitHub repos, and the main one has 90+ PRs open for some for over 8 months with no feedback. What is the point of this call to action if the current team can't handle the current PR volume? As it stands more PRs won't help the project.

Re: A Call for Developers – Jellyfin

#92
post #91

I just took a look at their GitHub repos, and the main one has 90+ PRs open for some for over 8 months with no feedback. What is the point of this call to action if the current team can't handle the current PR volume? As it stands more PRs won't help the project.

To be more specific, I looked at the list of open feature requests, and one of them is this one: https://github.com/jellyfin/jellyfin/issues/1714

A rather trivial PR for it is open since Feb 2023 with no addressable feedback: https://github.com/jellyfin/jellyfin/pull/9291

Re: A Call for Developers – Jellyfin

#93
post #54

Earlier quoted context omitted.

I agree. Media specific OSes are just okay but I have no problem about plugging my laptop into an HDMI cable to watch something. I have no anxiety about how a laptop sitting on a tv stand will look.

It's not an OS, it's a client-server application. Ignoring physical appearances, it presents large libraries nicely and allows you to use your phone or remote instead of needing to fiddle with a laptop. A few other nice features: can stream different content to multiple devices, users can be given access to specific libraries, and content can be age gated.

The abstraction between the two is a very minimal difference. My point stands is that as far as how things are controlled is a minimal issue. Streaming to multiple devices, library access, and age gates are nice features but they’re all mostly unnecessary and born out of the anxiety that the laptop connected to an HDMI port isn’t good enough.

Re: A Call for Developers – Jellyfin

#94
post #48

Sorry for the rant, but as someone who has used Jellyfin and similar apps like Kodi, I have to say I find their code quality and general software architecture to be crap. I wish there was a good alternative. A few examples: I have installed the Jellyfin server on a Linux box, and the Jellyfin app on a playback device (Google Chromecast with Google TV, GCCWGTV). When the app detects the playback device or TV doesn't s…

To be fair they are still refactoring code that they inherited from emby which they quite criticized before iirc.

Re: A Call for Developers – Jellyfin

#95
post #27

I do not understand why anyone uses Jellyfin, I've tried it twice, and it seems soo finicky and opinionated. I've always just had a Linux computer hooked up to the T.V. Add a little bit of ktorrent, VLC, and SMB. Never really had any problems with this and its much much simpler.

Jellyfin lets me flexibly provide whatever video/music content I want to my family.

In an interface that is basically "Netflix" - so they can actually figure out how to use it.

You just listed like 4 applications, a linux box, and physical cables as your requirements. That is not a workable starting point for that discussion.

My requirements are "Go to jellyfin.[mydomain]" and log in. It works basically everywhere (I am currently watching content from my jellyfin server while on vacation in a different state as I type this).

Basically - you are optimizing for "low setup cost" as an admin. Jellyfin is optimizing for the entire group of people who will watch your content as users.

As an aside... Sonarr/Radarr/Jellyfin are just a different league than the old school "I'll download every episode myself" time sink. It takes some genuine effort to setup, and then everything is way better.

Re: A Call for Developers – Jellyfin

#96
post #27

I do not understand why anyone uses Jellyfin, I've tried it twice, and it seems soo finicky and opinionated. I've always just had a Linux computer hooked up to the T.V. Add a little bit of ktorrent, VLC, and SMB. Never really had any problems with this and its much much simpler.

I agree. Media specific OSes are just okay but I have no problem about plugging my laptop into an HDMI cable to watch something. I have no anxiety about how a laptop sitting on a tv stand will look.

It's not a media OS.

You're thinking something like XMBC...

Jellyfin is more equivalent to a streaming app - but the backend is running in your private server.

Clients are available for the vast majority of consumer TV oses (Roku/Apple/AndroidTV/Web/Etc)

Re: A Call for Developers – Jellyfin

#97
post #27

I do not understand why anyone uses Jellyfin, I've tried it twice, and it seems soo finicky and opinionated. I've always just had a Linux computer hooked up to the T.V. Add a little bit of ktorrent, VLC, and SMB. Never really had any problems with this and its much much simpler.

I mean, it tracks metadata and progress centrally. It has clients for various low power appliance type devices as well as web.

If you have more than one TV it's nice to use a cheap android TV device set up to connect to jellyfin on each rather than move your laptop around.

It's also good for a road warrior. I can VPN to my house and steam elsewhere, and it does transcoding on the fly so it works over bad connections too.

And if you want to use VLC or whatever you can still use the web UI to find the media you want and download it.

Re: A Call for Developers – Jellyfin

#98
post #62

Earlier quoted context omitted.

You're likely in for a treat if you haven't written C# in a while. The language has evolved quite a bit, especially around all kinds of nice ergonomics. Interesting things like pattern matching, using statements, and performance oriented primitives. I got back to writing C# full time earlier this year and it's a joy.

I've been keeping up with the language and I am... Less than enthused. Maybe I'm just yelling at clouds, but I see more bloat than useful features recently. Non-nullable reference types as default was a bad idea and I will die on this hill

> Non-nullable reference types as default was a bad idea

Why?

Re: A Call for Developers – Jellyfin

#99

Earlier quoted context omitted.

I've been keeping up with the language and I am... Less than enthused. Maybe I'm just yelling at clouds, but I see more bloat than useful features recently. Non-nullable reference types as default was a bad idea and I will die on this hill

> Non-nullable reference types as default was a bad idea Why?

Lots of reasons, but mainly that I don't consider null values to be a fault of the language. Even if it were, this doesn't solve that problem.

But now we're in a situation where we still have nulls, but compiler warnings force us to decorate them and treat them the same as before. It obscures the difference between value and reference types. Plus the syntax implies Nullable, which is something everyone should have learned to avoid when all it did was box value types.

The more correct solution would have been to finish the contract system that allowed you to declare a function argument as non-nullable.

Ultimately I think it was the wrong solution to something that wasn't a problem to begin with. Now we have muddied the syntax and the null situation is the same as it always has been.

Re: A Call for Developers – Jellyfin

#100

Earlier quoted context omitted.

C# runs natively on Linux (have done for many years now). AFAIK even on Azure people prefer to run it on Linux machines (including the place I work for). Performance wise I believe it runs equal to faster. A lot of C# devs (majority) now work on none Windows machines (they were very quick to add support for the new Mac arch as well). TLDR; C# the language is as good or even better on none-Windows nowadays.

This is only true if you're talking about non-GUI apps. MAUI is trying to fix this but in my experience it has been a rocky start. But for backend and CLI stuff totally agree, works great on Linux

CLI is one of my biggest pain points with C# on Linux. A lot of the Console functions simply don't work because they're expecting an entirely different kind of console. Just clearing the screen doesn't work, you have to sneakily pass a "clear" string to the input stream, or something like that.

Console drawing is an enormous pain. I went to a lot of effort to optimize my console writes to construct graphics quickly, and it just does not work on Linux. I'd have to switch to a curses type library and it just makes me sad :(

Post reply on HN