Why on earth, when you go to 192.168.whatever:8096 does it ask you what server you want to connect to? Like.. THE ONE SERVING THE PAGE.
Just now I decided to connect to Jellyfin over tailscale and it's asking me to add a server; on 100.xxx, which is the jellyfin server which served the UI. And it doesn't seem to want to accept any answer as to what the server URL is.
This lets you connect to and play another friend's Jellyfin rather nicely. I think it's also so the HTML and JS that forms the web interface can basically be the app as well.
> And it doesn't seem to want to accept any answer as to what the server URL is.
Should be "http://192.168.100.xxx:8096" - make sure your jellyfin isn't just set to listen on localhost only though.
They've sort of conflated three different ideas - one, the non-browser clients are separate and need a way to select multiple servers from a common wrapper app; two, for development purposes separate the server of the UI package from the backend being accessed; three, have a server based application.
None of these items are uncommon, they are just commonly solved by making the separate front-end server an exception rather than a weird and senseless default. Most people solve this by making the dev mode case an exception.
Moreover, why not just add a button to the UI to automatically connect to the _UI serving server_ instead of having the user type it?
I love jellyfin, but this stuff is just terrible design for out of box experience or connecting from a new client instance, and it breaks when you're traversing a network boundary with something like Tailscale.
$ podman run --rm -it -p 8096:8096/tcp jellyfin/jellyfin
That said, I might've found a clue: if you re-run it, you get another randomized hostname, and then you get the server select page. If I clear cookies and reload, it again skips the server select page. So it seems like if you have the hostname of your jellyfin instance change, say, by starting a new Docker container with a different name, but have it accessible at the same place, that might cause this weirdness.
Other issues may include improperly configured reverse proxies. (If you're using a reverse proxy, you should make sure it's configured right for Jellyfin's websockets and CORS usage and potentially some other stuff.)
I don't know what the answer is, but I ran into this when I was trying to harden my systemd settings. I'll link my override below and maybe someone can give something more conclusive (and any suggestions to my override or for other services are greatly welcomed. I'm happy to add even ones I don't use). Where I hit this error was when messing with RestrictAddressFamilies, which are network socket addresses. For example, when I restrict AF_PPPOX or AF_UNIX I get that issue. IIRC I also hit that issue when I had moved a file, but I forgot which one (I noticed it got autogenerated again). So I suspect it has to do with access to some file location where it stashes a config file. Fwiw, this works with tailscale just fine.
https://github.com/stevenwalton/.dotfiles/blob/master/skelet...
(docs for RestrictAddressFamilies) https://www.freedesktop.org/software/systemd/man/latest/syst...
Chromecast support is flaky. Most of the time when I cast from my Android phone, the app immediately "forgets" that there's something playing back on the Chromecast (even though it's still connected to it), so I can't control playback at all. It's also hit or miss if the Chromecast will successfully play the media if Jellyfin decides it needs to transcode it.
So I got a little NUC-like box (Intel N100), and installed Jellyfin on it (it was previously running on an old 2012 Mac Mini running Linux). I connected it directly to the TV and installed jellyfin-media-player on it, set to auto-login and start X on boot, with a minimal session that just runs JMP only in fullscreen mode. I use JMP on my laptop, or the Android app, to control it. JMP will randomly lose its connection to the Jellyfin server (even though it's running on the same machine), and won't try to reconnect, so nearly every time I go to use it, I have to ssh in and restart JMP so it reconnects.
On top of that, I get occasional audio dropouts when watching 4k content, and sometimes see 4k video stuttering (yes, hardware decoding is enabled for playback, and I've verified in the logs that it's being used). At those times, the box is around 40% idle, and intel_gpu_top shows that the decode and render bits have what I think should be more than enough headroom to avoid that sort of thing. I understand JMP uses libmpv for playback, so out of curiosity I tried playing video using mpv directly, and somehow JMP's player uses about 50% more CPU than mpv standalone does, and I don't hear any dropouts or see any stuttering on the same media. I get that a video player that's embedded in an application might have some overhead, but 50% is a bit much.
I get that Jellyfin is maintained by volunteers (I also maintain open source in my spare time, so I know how tough it can be to be responsive to user requests), but these issues are quite frustrating. I don't want to use something closed like Plex or Emby (which may or may not be better), so it's still the right trade off for me. And what it can do is truly amazing. I love that I can play things while I'm on the go, VPN'ing to my home network, and Jellyfin will transcode down to a crappy-enough bitrate to fit within the confines of my garbage Comcast upload speed.
This might be more the Chromecast's fault as I've had a similar experience with Plex.
what are you referring to?
There was something that worked, going forward the core team decided to focus on a tight stream lined core and decruft 'features'.
Discussion:
https://old.reddit.com/r/selfhosted/comments/1dbiw90/skip_in...
https://forum.jellyfin.org/t-intro-skipper-project-dead
Seems like a temporary (indefinite) suspension and a storm in a teacup from those attached to the feature.
There is one big exception though: if you're watching Star Trek: Enterprise. The "skip intro" feature is invaluable so you don't have to be subjected to that truly horrific opening song.
But I hear ya, console support tends to lag behind because of the rules and costs of app dev for them
* It's always been quite slow and flaky. Library not scanning things, media library not connectable, etc.
* Often very long delay from starting a show until it actually plays. Often very slow scrubbing/skipping.
* The automatic subtitle downloading never works. The manual subtitle downloading never works.
* The UI was getting on my nerves trying to offer "recommendations" — I download my own stuff and don't need an app to try to push my own media through some kind of algorithm that's broken — and constantly promoting the Plex streaming service.
I got fed up and set up Jellyfin with Infuse as the client. Now shows start immediately with no buffering delay, never have any glitchy library issues, and the subtitle downloading just works.
My main issue is that Jellyfin's matching can be quite poor. It often doesn't understand when episodes belong to a show. Also, Infuse's UI is pretty bad and doesn't align at all with how I think media should be accessed.
I came from Plex a few years ago after their login server had an outage and I was unable to access the media that was on my local computer. Before that I'd been annoyed by them pushing TV shows and since then I've heard about them giving reports on what people have watched. All in all I'm happy.
My setup is Jellyfin in a docker container running on a debian machine with an i7-1165G7. It's got a mounted NFS link to my Synology NAS with all the files. The main client I used is Android TV running on an NVIDIA shield.
All in all, it's been great. I've got a few nitpicks---loading on ios app isn't as fast as I like if I try to jump to the middle of a movie---but all in all it's great for just watching movies, tv shows, videos, &c. All without any link to the outside world. It's lovely.
They also are producing new features at a nice clip and have a strong community. I expect it to keep getting better and better, but honestly even if it never changed I'd happily use it for years.