[Issue]: Jellyfin not binding to all addresses after update from 10.8.13 to 10.9.1 #11627
Comments
|
Hi, it seems like your issue report has the following item(s) that need to be addressed:
This is an automated message, currently under testing. Please file an issue here if you encounter any problems. |
|
If you leave the bind address setting blank what will it bind to? |
|
Having the same Issue |
The log shows the bind addresses for a blank setting. It binds to some of the available addresses but not 192.168.1.0/24 and tries to bind to 1.2.3.4 for some reason. |
Can you show an output of |
|
Something similar happens to me, when upgrading from 10.8.13 to 10.9.1 ip addr show: As it stands, I can't access the webui to try any setting changes. Edit: |
|
You can set the binding addresses manually in networking.xml in the jellyfin configs. This solves the issue for me at least (I'm running bare metal not docker) |
Thanks! I used the docker containers address and it fixed that for me as well |
|
yes this happens on version 10.9.0 and 10.9.1 also, only solution is to restart jellyfin.service after restart it binds normally and works as expected |
|
What's the best fix for this? I've tried removing network.xml altogether, tried adding the IP address and subnet for the docker container and the Unraid IP to no avail. I'm running Jellyfin through docker on Unraid. [19:24:05] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN addresses: ["172.17.0.0/16"] |
Im struggling inserting the IP Address in the Network.xml can you show the parts that you changed? |
|
I've inadvertantly ended up setting up a new server which appears to be working fine on 10.9.1. There must be an issue somewhere with the previous builds network settings that 10.9 is not happy with. |
Sure; I added the addresses like this: This bound the service to the containers IP. After restarting the container, I was able to reach the webui and remove this addresses again, as I don't want it to go offline again when the docker containers IP changes. Leaving it empty binds it to all available addresses afaik (which is fine in my case). |
|
Well it seems like we are divided here. Can you clarify that we are having issues that is related to Jellyfin does not wait for all interfaces up like described in #11591, or there are separate issues? Like the docker related ones are probably not related to this one. |
|
@ChrisRosser what is
Can you please reboot your system and run You can also try the solution posted in #11591 (comment) but I'm not confident that will help, since your system is definitely waiting for something to come up (i.e. |
|
We also found an Ubuntu- and Netplan-specific bug that might be relevant: bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/2063973 If you can see if you're affected by that bug, it might provide more answers. |
|
Facing the same issue here as well. Jellyfin is installed through the Debian package and it's binding to some interfaces but not all. Like others here, I upgraded from 1.8.13 -> 1.9.1 For me, I have a Caddy docker container as a reverse proxy, but Jellyfin is not listening on the Docker gateway IP (ex: 172.17.0.1) and also not on a WireGuard interface I use for VPN access. The issue also persists after restarting the Jellyfin service after all interfaces are up, etc. |
|
Had a similar issue running on a Hyper-V server, changing this line in Network.xml from true to false worked for me.
|
|
#11548 (comment) maybe relative |
fake0 is a dummy interface created by cockpit (https://cockpit-project.org/) removing the interface and cockpit does not help. Here is the startup.svg
|
Tried this and it didn't help unfortunately. My network adaptor is not virtual. |
|
More information and I think we are moving towards a diagnosis: #11591 seems to be an identical problem. Jellyfin is starting up before the main network interface is up and because that interface does not have a static IP it cannot bind to it. |
|
The cause of the problem is changing this behaviour in 10.9: 
Might be worth reverting this change? |
|
I have fixed the issue on my end by waiting for a wireguard interface to come up which delays jf starting until after the internet connection is live and the ip has been assigned. sudo nano /lib/systemd/system/jellyfin.service change the After= line to another service which only starts with a valid internet connection. |
|
@ChrisRosser I don't think reverting is the correct fix here. The OS is responsible for managing the networking interfaces and your service and network manager (usually systemd and networkManager/networkd/netplan) for making sure the requirements for your service are met. If they don't it's not the application's responsibility to fix it in my opinion. |
|
I would agree with you in theory, why should you have to fix someone else's
problem?
However, in practice leaving the usability of Jellyfin degraded because a
change has exposed a number of users to a bug they were previously
protected from is not a defensible position. Unless this change has
provided more users with an advantageous feature I am unaware of?
There is a separate question of whether NetworkManager is actually bugged.
It's returning that the interface is up and running (which it is) but it
has not yet received its IP address from the router. This may be correct
behaviour. It doesn't seem sensible to wait for DHCP to assign an IP
address to every interface (which may never happen) before starting other
services.
…On Wed, 15 May 2024, 10:29 Tim Eisele, ***@***.***> wrote:
@ChrisRosser <https://github.com/ChrisRosser> I don't think reverting is
the correct fix here. The OS is responsible for managing the networking
interfaces and your service and network manager (usually systemd and
networkManager/networkd/netplan) for making sure the requirements for your
service are met. If they don't it's not the application's responsibility to
fix it in my opinion.
—
Reply to this email directly, view it on GitHub
<#11627 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AJ7G7Y6G36YNJO4BXCTOUQLZCMTF5AVCNFSM6AAAAABHVVUM4KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJSGAZDEMJZGU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
This also might just be a bug in out network code not picking up the changed network state. I'll look into it later today. |
If you want to do that, please add that with #11253 Because dotnet's network status detection is extremely unreliable and we have to disable it for sanity. It could even lead to more bugs than it resolves (some broken OS/networking config). |
|
@gnattu we are already listening on network change events and react on them, that's why I'm a bit astonished we don't pick up the new interfaces (see link below). @ChrisRosser can you enable debug logging and check if you get any of these log lines at any point? |
Because that is implemented solely for plugins, the main server won't respond to this, and in my opinion, should not respond to this due to the broken implementation. |
Shouldn't this bind the main server to the change events? It has been like this in 10.8 too and it worked fine. |
No, the server won't relisten to new interfaces by this solely. Probably just because 10.8 bind to everything that happened make this to work. |
|
I just tried it:
So I'd be interested in debug logs from people where this apparently does not work. |
|
I'm having the same problem. using window server 10.9.1. This is a partial log message.
|
Yes I get these lines immediately after startup. However, I still cannot access Jellyfin on 192.168.1.109. It would seem only the bind addresses detected the first time work for the web interface. Perhaps these new bind addresses are not propagating somewhere they need to? This would explain why restarting jellyfin (but not rebooting) fixes the issue. [2024-05-15 15:33:12.266 +00:00] [INF] Core startup complete |
If you add an additional network interface after JF is started (while its running) can you then access the web-gui at the IP address of the new interface? Does the new bind address propagate through as a new address for the web-gui? |
Nope, this is because Kestrel can't reload it's config on the fly (I was unaware of this). So there really is no real way except binding to |
Cool, that explains it. I wanted to mention that even if I specify the binding address in the web-gui Jellyifn won't ever bind to that address unless it is also present on a network interface at startup. I think it would make sense (especially if you can't reload the config) to add explicitly specified binding addresses to the list at startup even if they aren't present on any interface. That way if they become available later they will still work. |
That is exactly what |
|
I am having this same issue but on Windows x64! I updated to 10.9.1 from 10.8.13 and since I have never been able to access the web interface. On inspection, there are no bind addresses assigned:
Any ideas what's going on? |
|
Issue still persists in Jellyfin docker 10.9.2 |
|
It's binding fine for you, you have an incompatible plugin: |
Please describe your bug
After updating from 10.8.13 to 10.9.1 Jellyifn no longer binds to my local 19.2.168.1.109 address. It still binds to my vpn 10.1.1.2 address and localhost. Networking is set to bind to all addresses and I have tried removing networking.xml to force a recreation of the file.
A workaround is to specify all the relevant addresses in "Networking > Bind to local network address" but this was not required with 10.8.13 and shouldn't be necessary.
Reproduction Steps
[2024-05-14 07:57:44.452 +00:00] [INF] Defined LAN addresses: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
[2024-05-14 07:57:44.452 +00:00] [INF] Defined LAN exclusions: []
[2024-05-14 07:57:44.452 +00:00] [INF] Using LAN addresses: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
[2024-05-14 07:57:44.453 +00:00] [INF] Using bind addresses: ["127.0.0.1", "1.2.3.4", "10.1.1.2"]
[2024-05-14 07:57:44.453 +00:00] [INF] Remote IP filter is "Allowlist"
[2024-05-14 07:57:44.453 +00:00] [INF] Filter list: []
Jellyfin Version
10.9.0
if other:
No response
Environment
Jellyfin logs
FFmpeg logs
No response
Please attach any browser or client logs here
No response
Please attach any screenshots here
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: