starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-05-04 18:09:12 +03:00
Code Issues 822 Packages Projects Releases 10 Wiki Activity

UPnP discovery not working for some devices #2566

New Issue
Closed
opened 2026-02-06 22:12:51 +03:00 by OVERLORD · 3 comments
OVERLORD commented 2026-02-06 22:12:51 +03:00
Owner
Copy Link

Originally created by @Skyr on GitHub (Jan 30, 2021).

Originally assigned to: @BaronGreenback on GitHub.

Describe the bug
One device in my LAN don't show Jellyfin as library. Works perfectly with others (Yamaha receiver, BubbleUPnP app, ...).
The device had no problem with minidlna. I tried creating an indiviual profile, but without success.

System (please complete the following information):

  • OS: Host: Ubuntu 20.10
  • Virtualization: Docker (host mode, official Docker image "jellyfin/jellyfin")
  • Clients: auna radio (model name in dlna: iRadio Renderer)
  • Jellyfin Version: 10.6.4
  • Installed Plugins: none
  • Reverse Proxy: traefik (though not relevant here)
  • Base URL: none
  • Networking: host
  • Storage: local

To Reproduce

  1. Turn on device
  2. Wait to boot up, wait some time for discovery - but list of UPnP media centers remains empty

Expected behavior
Jellyfin should be discovered properly

Logs
Verbose dlna logging enabled, the logs show the following trace:

[2021-01-30 11:14:01.677 +01:00] [INF] [4] Emby.Dlna.Main.DlnaEntryPoint: DLNA Session created for "Kuechenradio" - "iRadio Renderer"
[2021-01-30 11:14:02.793 +01:00] [ERR] [22] Emby.Dlna.Main.DlnaEntryPoint: Error updating device info for "Kuechenradio"
System.Net.Http.HttpRequestException: An error occurred while sending the request.
 ---> System.IO.IOException: The response ended prematurely.
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   --- End of inner exception stack trace ---
   at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithNtConnectionAuthAsync(HttpConnection connection, HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken)
   at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts)
   at Emby.Server.Implementations.HttpClientManager.HttpClientManager.SendAsyncInternal(HttpRequestOptions options, HttpMethod httpMethod)
   at Emby.Server.Implementations.HttpClientManager.HttpClientManager.SendAsync(HttpRequestOptions options, HttpMethod httpMethod)
   at Emby.Dlna.PlayTo.SsdpHttpClient.SendCommandAsync(String baseUrl, DeviceService service, String command, String postData, String header, CancellationToken cancellationToken)
   at Emby.Dlna.PlayTo.Device.GetTransportInfo(TransportCommands avCommands, CancellationToken cancellationToken)
   at Emby.Dlna.PlayTo.Device.TimerCallback(Object sender)

I'm not sure how far any protocols have progressed at this time.

tcpdump shows the multicast announcements, the xml at the radio's discovery location seems to be properly parsed, since the logs show the manufacturer details.

In the dump, I see this failed http request from the radio to Jellyfin:

GET /dlna/f7678db700764c99b61a2b324f93d514/description.xml HTTP/1.1
HOST: 192.168.178.2:8096
DATE: Sat Jan 30 10:45:21 2021
USER-AGENT: Linux/2.4.22, UPnP/1.1, Internet Radio device /1.2
CONNECTION: close

HTTP/1.1 400 Bad Request
Connection: close
Date: Sat, 30 Jan 2021 10:45:20 GMT
Server: Kestrel
Content-Length: 0

I don't know how these two are related.

Originally created by @Skyr on GitHub (Jan 30, 2021). Originally assigned to: @BaronGreenback on GitHub. **Describe the bug** One device in my LAN don't show Jellyfin as library. Works perfectly with others (Yamaha receiver, BubbleUPnP app, ...). The device had no problem with minidlna. I tried creating an indiviual profile, but without success. **System (please complete the following information):** - OS: Host: Ubuntu 20.10 - Virtualization: Docker (host mode, official Docker image "jellyfin/jellyfin") - Clients: auna radio (model name in dlna: iRadio Renderer) - Jellyfin Version: 10.6.4 - Installed Plugins: none - Reverse Proxy: traefik (though not relevant here) - Base URL: none - Networking: host - Storage: local **To Reproduce** 1. Turn on device 2. Wait to boot up, wait some time for discovery - but list of UPnP media centers remains empty **Expected behavior** Jellyfin should be discovered properly **Logs** Verbose dlna logging enabled, the logs show the following trace: ``` [2021-01-30 11:14:01.677 +01:00] [INF] [4] Emby.Dlna.Main.DlnaEntryPoint: DLNA Session created for "Kuechenradio" - "iRadio Renderer" [2021-01-30 11:14:02.793 +01:00] [ERR] [22] Emby.Dlna.Main.DlnaEntryPoint: Error updating device info for "Kuechenradio" System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.IO.IOException: The response ended prematurely. at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.Http.HttpConnection.SendAsyncCore(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.SendWithNtConnectionAuthAsync(HttpConnection connection, HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.SendWithRetryAsync(HttpRequestMessage request, Boolean doRequestAuth, CancellationToken cancellationToken) at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpClient.FinishSendAsyncUnbuffered(Task`1 sendTask, HttpRequestMessage request, CancellationTokenSource cts, Boolean disposeCts) at Emby.Server.Implementations.HttpClientManager.HttpClientManager.SendAsyncInternal(HttpRequestOptions options, HttpMethod httpMethod) at Emby.Server.Implementations.HttpClientManager.HttpClientManager.SendAsync(HttpRequestOptions options, HttpMethod httpMethod) at Emby.Dlna.PlayTo.SsdpHttpClient.SendCommandAsync(String baseUrl, DeviceService service, String command, String postData, String header, CancellationToken cancellationToken) at Emby.Dlna.PlayTo.Device.GetTransportInfo(TransportCommands avCommands, CancellationToken cancellationToken) at Emby.Dlna.PlayTo.Device.TimerCallback(Object sender) ``` I'm not sure how far any protocols have progressed at this time. tcpdump shows the multicast announcements, the xml at the radio's discovery location seems to be properly parsed, since the logs show the manufacturer details. In the dump, I see this failed http request from the radio to Jellyfin: ``` GET /dlna/f7678db700764c99b61a2b324f93d514/description.xml HTTP/1.1 HOST: 192.168.178.2:8096 DATE: Sat Jan 30 10:45:21 2021 USER-AGENT: Linux/2.4.22, UPnP/1.1, Internet Radio device /1.2 CONNECTION: close HTTP/1.1 400 Bad Request Connection: close Date: Sat, 30 Jan 2021 10:45:20 GMT Server: Kestrel Content-Length: 0 ``` I don't know how these two are related.
OVERLORD added the bugstale labels 2026-02-06 22:12:51 +03:00
OVERLORD commented 2026-02-06 22:12:54 +03:00
Author
Owner
Copy Link

@BaronGreenback commented on GitHub (Jan 31, 2021):

The main discovery is done over UDP in a protocol called SSDP.

Once the devices have notified each other, then it moves across to http using SOAP requests.

Each device, during the advertisement phase transmits an "here am i - and this is my description" url. This is what JF uses to build up the device properties.

The error shown above is actually quite normal in that it happens when JF queries the device, but the device does not respond as it's otherwise engaged. (The error should really be a debug message.) In order to send this, it should have already discovered the device.

The tcpdump msgs you need to look at are the ones that return .xml data such as above.

Any coming inbound to JF can be ignored, as that is the devices querying the JF DLNA server for info.
It's the ones going from JF and their responses which will help.

Try enabling debug via the web and in the logging.default.json, but beware it fills the logs very quickly,

Also be aware, DLNA isn't IPv6 aware in this release.

@BaronGreenback commented on GitHub (Jan 31, 2021): The main discovery is done over UDP in a protocol called SSDP. Once the devices have notified each other, then it moves across to http using SOAP requests. Each device, during the advertisement phase transmits an "_here am i - and this is my description_" url. This is what JF uses to build up the device properties. The error shown above is actually quite normal in that it happens when JF queries the device, but the device does not respond as it's otherwise engaged. (The error should really be a debug message.) In order to send this, it should have already discovered the device. The tcpdump msgs you need to look at are the ones that return .xml data such as above. Any coming inbound to JF can be ignored, as that is the devices querying the JF DLNA server for info. It's the ones going from JF and their responses which will help. Try enabling debug via the web and in the logging.default.json, but beware it fills the logs very quickly, Also be aware, DLNA isn't IPv6 aware in this release.
OVERLORD commented 2026-02-06 22:12:55 +03:00
Author
Owner
Copy Link

@BaronGreenback commented on GitHub (Jan 31, 2021):

There are numerous things currently being worked on in the next release, including Auto profile creation, and DLNA tracing to aid in issues like this.

@BaronGreenback commented on GitHub (Jan 31, 2021): There are numerous things currently being worked on in the next release, including Auto profile creation, and DLNA tracing to aid in issues like this.
OVERLORD commented 2026-02-06 22:12:56 +03:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Aug 21, 2021):

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.

@stale[bot] commented on GitHub (Aug 21, 2021): This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label. This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on [Matrix or Social Media](https://docs.jellyfin.org/general/getting-help.html).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label bug stale
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#2566
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?