+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: Troubleshooting (https://forum.jellyfin.org/f-troubleshooting)
+---- Forum: Networking & Access (https://forum.jellyfin.org/f-networking-access)
+---- Thread: DLNA plugin - only parts of the functionality working with my client (/t-dlna-plugin-only-parts-of-the-functionality-working-with-my-client)
DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-04-11
I got a DLNA client A, a Synology DLNA server and a JF DLNA server. Both server are currently running in parallel while I'm testing JF with the intention to replace the Synology.
Testing with music media, Synology is supporting the whole functionionality the DLNA client is offering: Browsing, play, stop, pause, next, previous, reapeat modes, random, loading cover picture. Interestingly on JF only browsing, play, stop, pause, loading cover picture are working.
I was assuming that next, previous, reapeat modes, random are client functionality which have nothing to do with the DLNA server. Same for Random and Repeat modes. Form the observed behaviour, this does not seem to be the case, it seems the DLNA server is involved somehow (wasn't able to find more information about this yet).
Before i start digging deeper, does someone know if
- this indeed is server side functionality?
- if this is supported by the DLNA plugin and known to be working?
- In case it is supported, where I could have missed something/why this is not working in my installation?
My next steps would be to
- try to find a DLNA specification
- tcpdump ing the communication
RE: DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-04-11
Two more interesting observations from the same client:
- The directory/file listing on JF is significantly slower than on the Synology, although JF has far more CPU power and RAM available.
- While on Synology album images are loaded once and displayed, the same client when connected to JF always loads album images 5 times, leading to a flickering display (i can see 5 http requests for the image from the client). Interestingly the request parameter (image id) is changing it time, although it's always the same image being displayed. I guess this is another indication something in the communication between client and JF is not working as it should.
I will try with another client aswell, maybe it's an interoperability problem.
RE: DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-04-11
After testing a bunch of combinations of clients with my two servers, it seems JF DLNA is a bit "picky" - some clients are working without issues (i.e. VLC, others have problems with limited functionality. The Synology Media Player is working with all clients I have tested without problem.
I couldn't find out why this is nor if the clients are implemented differently. I.e. I can imaging "next" could be implemented differently: It could be a "relative" command sent to the server, unstructing the server to play the next song in an album, but it also could be the client just stopping the current song and sending a play command for the next song in the song list the client has received before. I haven't tracked this down in detail, so I don't know if this is about different implementions. Fact is, JF DLNA is not fully working with every client.
--
Have to correct myself: VLC isn't fully working with JF. Browsing is buggy, listing does only work for "genres" and "albums", all other categories fail to list. So no browsing of trees and folders... Maybe it's a timeout problem? 420 Interpreters isn't that much, that should be read from an index within fractions of a second....
RE: DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-04-26
After testing the DLNA plugin with various clients and comparing it to Synology, my conclusion is:
- it only offers a reduced feature set, even basic features are missing.
- performance is slow
- signifantly worse compared to the DLNA implementation in Synology
Bottom line, it's only usable if you don't need more than pick a song an play it. Otherwise would will have to work with playlists, which you start and let run without skipping or repeating.
I didn't had a look at the code, however in the github repo I couldn't detect a lot of activities. It rather seems the plugin has been left back to die in peace.
RE: DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-05-09
Digging into the plugin's code, did I get this right, "MediaBrowser" is a shared service from the Jellyfin main application offering access to media lists?
I'm asking as from what i experience, listing of media is terribly slow in the DLNA plugin, so I'm trying to find the root cause. The plugin itself doesn't seem to do a lot regarding listing, it seems to be more or less consuming data from the Jellyfin's datamodel represented by the "MediaBrowser". Did i get this right?
This also means, the plugin itself is not holding/managing an index. Does "MediaBrowser" use a media file cache/index? I can see Jellyfin consumiung a fair amount of RAM even when idle, so my thoughts are, that this cache/index could be hold in memory? I'm asking the listing from then DLNA plugin is so slow that not caching/keeping the file list in memory could be an explenation.
Other than this: Did I get it right that the DLNA device's profile doesn't have an effect in performance and how lists are handled? That's a least the impression I get from reading the profile's xml files.
RE: DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-05-09
Just as reference: We're talking about roughly 25k mp3 files in 3500 dirs, each dir being an interpreter or an album. JF has scanned the folders/lib and browsing in the web interface works with adequate speed.
However, i.e. when using VLC, listing "Interpeters" it takes minutes until the server returns the repons with the file list, often running into a timeout not returning anyhting. Looking at the server during this request, there is no high CPU, no high I/O, no high network usage. Also there is no iowait. So there is no indication it could be a ressources limitation. Atm everyhing points to JF and/or the plugin.
Doing the same request from a second VLC instance in parallel to an old Synology Media Server, with fractions of CPU power and RAM available compared to the JF application, Synology returns within a couple of seconds.
Doing the same from an Denon AVR as DLNA client, the situation is exactly the same - Synology "fast", JF slow with timemouts and almost unsuable.
Btw, is the plugin still maintained at all? On github there are dozens of issues reported going back to 2022 and almost none seems to be touched at all.
RE: DLNA plugin - only parts of the functionality working with my client - bitstream - 2025-05-10
Another evidence the Index/cache is not working efficiently: I added just a few favourites. The list is displayed at once when selected in the client. So the problem seems to origin from larger file/dir lists which JF needs to handle when Interpreters or Songs etc. are called.
Is there a log or debug option to find out about JF internal processing times for media listing? Any log or debug information related to indizes or caches? In the JF log I can see zero logs from DLNA. Also in the long running requests logs nothing from DLNA.