Open arpel opened 2 months ago
(with jellyfin_10.9.2-amd64) I have the same problem. I did a clean install from scratch but I can't stream to my Samsung TV anymore. With the previous version jellyfin_10.9.1-amd64 worked without problems
Thanks, just tried 10.9.1 (went straight from 10.8 to 10.9.2) and can confirm it immediately works.
What happened on 10.9.2 ? Might not be plugin related ?
I honestly wouldn't know what to tell you. We'll have to wait and see what's new. I assume it has to do with changes between versions of the Jellyfin server (because the plugin is the same for both versions)
I leave screenshots confirming that with jellyfin10.9.1 DLNA it works without problems
Hi, same issue here with the "Cast to device/Play on" option. I was on an old jellyfin version (I think 10.8.x) and recently switch to 10.9.? and DLNA plugin was working. Yesterday I updated to 10.9.2 and plugin stopped working
Hi, I think this is related to the various modifications of NetworkManager in the core application in 10.9.2.
If it fails when "bind address" field is empty in the network configuration tab, it actually works, even on 10.9.2 when I fill this field with local LAN IP of the server.
When doing so, the DLNA sessions are created and the targets appear in "Play to" menu :
[2024-05-19 09:10:18.133 +00:00] [DBG] [23] Jellyfin.Plugin.Dlna.ContentDirectory.ContentDirectoryService: Creating event subscription for "upnp:event" with timeout of 180 to "<http://192.168.0.31:49200/>"
[2024-05-19 09:10:21.015 +00:00] [DBG] [23] Jellyfin.Plugin.Dlna.Main.DlnaHost: Attempting to create PlayToController from location http://192.168.0.31:60006/upnp/desc/aios_device/aios_device.xml
[2024-05-19 09:10:21.063 +00:00] [DBG] [3] Jellyfin.Networking.Manager.NetworkManager: Trying to get bind address for source "192.168.0.31" - External: False
[2024-05-19 09:10:21.064 +00:00] [DBG] [3] Jellyfin.Networking.Manager.NetworkManager: "192.168.0.31": No matching bind address override found
[2024-05-19 09:10:21.064 +00:00] [DBG] [3] Jellyfin.Networking.Manager.NetworkManager: "192.168.0.31": Internal request received, matching internal bind address found: "192.168.0.61"
[2024-05-19 09:10:21.066 +00:00] [DBG] [3] Jellyfin.Plugin.Dlna.Main.DlnaHost: Dlna Device.Start
[2024-05-19 09:10:21.068 +00:00] [DBG] [3] Jellyfin.Plugin.Dlna.DlnaManager: Found matching device profile: "Marantz"
[2024-05-19 09:10:21.072 +00:00] [INF] [3] Jellyfin.Plugin.Dlna.Main.DlnaHost: DLNA Session created for "Marantz NR1200" - "Marantz NR1200"
Configuration field is in Dashboard -> Advanced -> Networking -> Bind to local IP : 192.168.0.61/24 (in my case)
Hello Arpel. Good job! I installed the jellyfin_10.9.2-amd64 version again to test and indeed, now you have to indicate the server IP in Dashboard -> Advanced -> Networks -> Link to local IP In my case it is the IP of my internal network 192.168.1.104.
for the DNLA plugin to work well. Everything is well now. Thank you.
hi, just to add more information/confirmation: it did work in .91 version but broke in .92 for me as well.
also, in my case, binding to a single address as proposed by @arpel did indeed seem to fix the DLNA problem: from what I saw in the logs, it could detect my DLNA Sony hifi,
but since I am using a docker "macvlan" network (instead of the "host" mode), this renders the web interface inaccessible: the "web network" is different from the "DLNA network". (in fact, I had to manually edit the network.xml
file to revert bc. I couldn't reach the GUI anymore...)
so in my case, I do indeed use 2 different addresses.
fyi, for now, I will just leave it as is and watch closely this issue. I can live without DLNA. but if this plugin cannot bind to multiple addresses anymore, may I suggest adding a "binding address" configuration field here too? in fact, I'd rather have that anyways since i'd rather not have the DLNA broadcasting in all networks anyways.
macvlan" network (instead of the "host" mode), this renders the web interface inaccessible: the
I too use macvlan, and we could specify two ips, make sure that the first one is your macvlan (the one for the DLNA)
In my case it looks like this (192.168.1.0/24 is my network for dlna(where each devices are))
hi, thx a bunch for the idea of putting more than 1 address there o0, it works for me too! that being said, that 2nd address being one that is dynamically allocated (by Docker), I still consider this a temporary solution (ie. it will_ fail in the future, more than probably when I'll have completely forgotten about all this...)
nb. for the ones using the jellyfin/jellyfin
Docker image like me: I also had to modify the env. variable HEALTHCHECK_URL=http://192.168.1.245:8096/health
because it defaults to localhost
.
otherwise, the container cannot properly start (ie. "starting" for a while, then "unhealthy")
After I put an address in " Link to local IP",I can link my tv.But the movie did not play.There is nothing displaying just a black screen.
This should now be fixed in #51. Restarting Jellyfin should update the plugin automatically, otherwise just update it manually to version 2.0.0.0.
FYI, 'just tested, and without manually setting the bind addresses, it can find the device: I see my "hi-fi" in the list & select it, it can send the play commands to the device: when I click the play button, the "hi-fi" display shows it is searching for something, but the "hi-fi" doesn't seem to find the server: it keeps searching but never finds anything ; after a timeout (~40secs), it abandons and tries the next song.
web_1 | [00:30:40] [INF] [55] Jellyfin.Plugin.Dlna.DlnaManager: No matching device profile found. The default will need to be used.
web_1 | {"FriendlyName": "CMT-MX700Ni/MX750Ni", "ModelNumber": null, "SerialNumber": null, "ModelName": "CMT-MX700Ni/MX750Ni", "ModelDescription": "Micro Hi-Fi Component System", "ModelUrl": null, "Manufacturer": "Sony Corporation", "ManufacturerUrl": "http://www.sony.net/", "Headers": [], "$type": "DeviceIdentification"}
^^^ this a bunch of times but seems normal: it appears also when everything is working correctly
web_1 | [00:31:22] [INF] [56] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app DLNA 10.9.2 playing The Forbidden Fruits Of Eden. Stopped at 0 ms
web_1 | [00:32:05] [INF] [55] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app DLNA 10.9.2 playing Everything Matters (feat. Pomme). Stopped at 0 ms
web_1 | [00:32:48] [INF] [56] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app DLNA 10.9.2 playing Giving In To The Love. Stopped at 0 ms
I don't know the thing at all, but my guess it sends the commands with a "source IP" from the wrong network.
nb: I notice that the 'NetworkManager' detects the expected address (192.168.1.245) last in its list.
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN subnets: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions: []
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Used LAN subnets: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"]
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered interface addresses: ["127.0.0.1", "172.18.0.5", "192.168.1.245"]
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Bind Addresses ["0.0.0.0"]
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Remote IP filter is Allowlist web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered subnets: []
thanks for your work, btw!
hi, me again, sorry! right when I clicked the "send comment" button, I got the notification that the v10.9.3 is out... so after updating & retesting, everything is now working correctly o_0 . it seems this issue is fixed for me
but I also noticed the interfaces got registered in a different order:
web_1 | [01:02:21] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered interface addresses: ["127.0.0.1", "192.168.1.245", "172.18.0.5"]
web_1 | [01:02:21] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Bind Addresses ["0.0.0.0"]
question, then: am I correct to understand this is only a question of chance that this is working ?
There was a DLNA plugin release that was supposed to fix IP binding issues, and a server release that was also supposed to fix IP binding issues.
I'm leaning towards the issue is fixed and not just chance 🤞
FYI, 'just tested, and without manually setting the bind addresses, it can find the device: I see my "hi-fi" in the list & select it, it can send the play commands to the device: when I click the play button, the "hi-fi" display shows it is searching for something, but the "hi-fi" doesn't seem to find the server: it keeps searching but never finds anything ; after a timeout (~40secs), it abandons and tries the next song.
web_1 | [00:30:40] [INF] [55] Jellyfin.Plugin.Dlna.DlnaManager: No matching device profile found. The default will need to be used. web_1 | {"FriendlyName": "CMT-MX700Ni/MX750Ni", "ModelNumber": null, "SerialNumber": null, "ModelName": "CMT-MX700Ni/MX750Ni", "ModelDescription": "Micro Hi-Fi Component System", "ModelUrl": null, "Manufacturer": "Sony Corporation", "ManufacturerUrl": "http://www.sony.net/", "Headers": [], "$type": "DeviceIdentification"} ^^^ this a bunch of times but seems normal: it appears also when everything is working correctly web_1 | [00:31:22] [INF] [56] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app DLNA 10.9.2 playing The Forbidden Fruits Of Eden. Stopped at 0 ms web_1 | [00:32:05] [INF] [55] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app DLNA 10.9.2 playing Everything Matters (feat. Pomme). Stopped at 0 ms web_1 | [00:32:48] [INF] [56] Emby.Server.Implementations.Session.SessionManager: Playback stopped reported by app DLNA 10.9.2 playing Giving In To The Love. Stopped at 0 ms
I don't know the thing at all, but my guess it sends the commands with a "source IP" from the wrong network.
nb: I notice that the 'NetworkManager' detects the expected address (192.168.1.245) last in its list.
web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN subnets: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"] web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Defined LAN exclusions: [] web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Used LAN subnets: ["127.0.0.1/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"] web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered interface addresses: ["127.0.0.1", "172.18.0.5", "192.168.1.245"] web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Bind Addresses ["0.0.0.0"] web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Remote IP filter is Allowlist web_1 | [00:20:38] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered subnets: []
thanks for your work, btw!
Strange, I'm still on 10.9.2 and with the new version of the plugin I can both find and stream to my DLNA music player without problems.
@ms-afk ok, FYI, re-retested today and even when reverting back to version .92 the issue does not reappear... but I also notice that the order of the interfaces in the logs is still the "correct" one: the "192.168" first
web_1 | [10:40:09] [INF] [1] Jellyfin.Networking.Manager.NetworkManager: Filtered interface addresses: ["127.0.0.1", "192.168.1.245", "172.18.0.5"]
so my guts feeling (and a little bit the code change in the merge request) is telling me it is taking the first address in the list (after the 127) and use it as source or something, and so rely on some "chance" to fall on the right one. but this is just a guess ; I am really not sure what happened yesterday nor how I can reproduce or refute that hypothesis ... in any case, this is another problem not related to this issue, so I consider this one closed.
again: thank you all for your work!
(and a little bit the code change in the merge request) is telling me it is taking the first address in the list
The code added in the pull requests only takes the first address if there is only one address present.
On the other hand the "old" code, still executed in some occasions, also takes the first address, but this address has to match the right network interface. The three addresses in your log should be assigned to three different interfaces, so, again, there should be only one matching address.
This means that the order of those addresses should not matter. It is however possible that something else has been broken after 10.9.2, that is dependent on the order of the addresses.
jellyfin:10.9.3 DLNA:2.0.0.0
After updating jellyfin and plugins,it still does not work well.
Thanks.
@zorro0109 this seems to be a totally different issue (session related), please open a new issue for it.
Updated to version 10.9.7
and DLNA-plugin version 2.0.0.0
yesterday/today. I also run on docker with macvlan. I read here and there in the linked other issues that it should not be necessary anymore to bind the server to local network addresses anymore. But with these versions I still need to do so. If I bind the server to the macvlan ip address and the docker internal ip address, then and only then I can hear music coming from my DLNA devices. If I remove the bindings and restart Jellyfin again, I can start to play a song/playlist but after a few seconds the next song is automatically playing and I loose the controls too. When I enter both ip addresses again in the Network section to bind the local addresses, it works again as expected.
Hi, I've just updated 10.8.x version to latest 10.9.2, installed additional plugin-dlna and I can't get "Play to" to list something... as it used to do on 10.8.
I'm able to browse and play from a device to the Jellyfin DLNA : should not be a network issue (and was working before...).
I am using the official docker container in host networking mode and basically changed nothing to the configuration.
There's nothing in the logs, could you help? Thanks!