MikFlix 2 Posted March 28, 2023 Posted March 28, 2023 Same behaviour on my Philips 65OLED807/12. Endless loading circle. It works normal on my 300€ Hisense TV.
Luke 42077 Posted April 17, 2023 Posted April 17, 2023 Please try the Emby DLNA plugin update version 1.1.4+ and let me know how that compares. Thanks !
le_hades 4 Posted August 4, 2023 Posted August 4, 2023 (edited) On 11/6/2022 at 8:12 PM, Techie-v2 said: Yeah as stated before, the server comes up in the list of sources, but just a spinning loading wheel.......as attached Before you turn emby on, the option on the tv is called "Simply Share" -don't know if that's just what philips called their dlna access option Thanks I'm using the docker version and finding the same thing (Emby 4.7.13.0 + DLAN Plugin 1.2.7.0) I have 2 different philips devices with android and i've tried different combinations always with the same results: - In both devices i've tested using the native dlna browser and an external dlna browser (VLC): native exhibits this behavior but VLC works OK - In both devices i've tested different dlna servers (Emby, Jellyfin, Kodi, Serviio, UMS...): Emby and jellyfin exhibit this behavior but other servers work OK Seems an issue with the initial browse request/answer. Attached you'll find 2 logs: one using the vlc browser and another with the native browser: - In the native log, after the initial browse request all traffic stops after the query... and almost two minutes later the keep alive kicks in (2023-08-04 09:25:47.645 Debug App: Begin Sending Alive Notifications For All Devices) during this time all the TV shows is the spinning loading wheel - In the vlc log everything works and the log shows all the expected traffic I would guess either the native player request is constructed in a way the server does not like or the player doesnt like the server's answer. Only difference i can see in the native player log is it doesn't include the "Accept-Ranges=bytes" header while de VLC log has it Hope somebody with more knowledge can work it out embyserver_vlc.txt embyserver_native.txt Edited August 4, 2023 by le_hades
Luke 42077 Posted August 4, 2023 Posted August 4, 2023 13 hours ago, le_hades said: I'm using the docker version and finding the same thing (Emby 4.7.13.0 + DLAN Plugin 1.2.7.0) I have 2 different philips devices with android and i've tried different combinations always with the same results: - In both devices i've tested using the native dlna browser and an external dlna browser (VLC): native exhibits this behavior but VLC works OK - In both devices i've tested different dlna servers (Emby, Jellyfin, Kodi, Serviio, UMS...): Emby and jellyfin exhibit this behavior but other servers work OK Seems an issue with the initial browse request/answer. Attached you'll find 2 logs: one using the vlc browser and another with the native browser: - In the native log, after the initial browse request all traffic stops after the query... and almost two minutes later the keep alive kicks in (2023-08-04 09:25:47.645 Debug App: Begin Sending Alive Notifications For All Devices) during this time all the TV shows is the spinning loading wheel - In the vlc log everything works and the log shows all the expected traffic I would guess either the native player request is constructed in a way the server does not like or the player doesnt like the server's answer. Only difference i can see in the native player log is it doesn't include the "Accept-Ranges=bytes" header while de VLC log has it Hope somebody with more knowledge can work it out embyserver_vlc.txt 79.53 kB · 1 download embyserver_native.txt 46.29 kB · 1 download What exactly happens on the TV? I think you’re right, that it doesn’t like something about the server’s answer. The question is what.
le_hades 4 Posted August 6, 2023 Posted August 6, 2023 During all this, the TV just shows a spinning wheel... like it is waiting for something (the same as the picture from @Techie-v2). My guess... it is waiting for an answer to the browse request it can understand. This doesn't happen with other media servers (Kodi, Serviiio, UMS...), this only happens with emby (and jellyfin... surely because of the forked code)
Luke 42077 Posted August 13, 2023 Posted August 13, 2023 On 8/6/2023 at 4:38 AM, le_hades said: During all this, the TV just shows a spinning wheel... like it is waiting for something (the same as the picture from @Techie-v2). My guess... it is waiting for an answer to the browse request it can understand. This doesn't happen with other media servers (Kodi, Serviiio, UMS...), this only happens with emby (and jellyfin... surely because of the forked code) One thing I notice that is unusual is it is sending Filter=*, which tells the server to include all possible data fields in the response. Usually most players tend to list out the specific fields that they'll utilize rather than just requesting *. So in turn the Emby Dlna server is adding everything it supports to the output, and there's probably something in it that Philips is getting hung up on. The question is what.
le_hades 4 Posted August 14, 2023 Posted August 14, 2023 (edited) On 8/13/2023 at 3:02 AM, Luke said: One thing I notice that is unusual is it is sending Filter=*, which tells the server to include all possible data fields in the response. Usually most players tend to list out the specific fields that they'll utilize rather than just requesting *. So in turn the Emby Dlna server is adding everything it supports to the output, and there's probably something in it that Philips is getting hung up on. The question is what. If you look at the VLC request it also sends Filter=* so it shouldn't be that weird. Also i guess the native client always sends the same request and it is able to process every other DLNA server answer but this. Maybe it is related to this and also the header i referenced (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges) that header implies support for segmented communication... maybe the native client does not support this, and being a big request the server is trying to segment it? Edited August 14, 2023 by le_hades
Luke 42077 Posted August 14, 2023 Posted August 14, 2023 10 hours ago, le_hades said: If you look at the VLC request it also sends Filter=* so it shouldn't be that weird. Also i guess the native client always sends the same request and it is able to process every other DLNA server answer but this. Maybe it is related to this and also the header i referenced (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Accept-Ranges) that header implies support for segmented communication... maybe the native client does not support this, and being a big request the server is trying to segment it? No, the server would only segment it if it was requested via a byte range request.
le_hades 4 Posted August 16, 2023 Posted August 16, 2023 I don't know then... Is there any other test i can run or something i should do? should I open an issue on github and link this info/thread?
Luke 42077 Posted August 17, 2023 Posted August 17, 2023 On 8/16/2023 at 8:44 AM, le_hades said: I don't know then... Is there any other test i can run or something i should do? should I open an issue on github and link this info/thread? You've come to the right place. No need to create a topic anywhere else. We'll just have to get a Philips in house so that we can get to the bottom of it ourselves.
le_hades 4 Posted August 18, 2023 Posted August 18, 2023 11 hours ago, Luke said: You've come to the right place. No need to create a topic anywhere else. We'll just have to get a Philips in house so that we can get to the bottom of it ourselves. Of course. Please let me know if there is something else i can help with. Thank you. 1
le_hades 4 Posted August 18, 2023 Posted August 18, 2023 (edited) Noticed I never reported the TV models. One is a 2021 65OLED705/12 (https://www.displayspecifications.com/en/model/cac926d9) The other a 2018 55PUS7503 (https://www.displayspecifications.com/en/model/d27810b5) In case you need it. Edited August 18, 2023 by le_hades 1
le_hades 4 Posted October 17, 2023 Posted October 17, 2023 Hey @Luke¿did you had the chance to look further into this issue? No pressure, just checking. Thank you.
le_hades 4 Posted January 30, 2024 Posted January 30, 2024 I'm guessing it's a low priority issue then, but to me it's the only thing keeping me from migrating my library to Emby. If and when this is looked at, please contact me if you need any more info or help. 1
meelis 0 Posted March 11, 2024 Posted March 11, 2024 Is this issue with Philips TV's is still not solved? I did a try with free version and it didnt worked with Philips. With LG was all ok.
le_hades 4 Posted March 11, 2024 Posted March 11, 2024 7 minutes ago, meelis said: Is this issue with Philips TV's is still not solved? I did a try with free version and it didnt worked with Philips. With LG was all ok. No, It isn't solved or at least I haven't heard anything about it. There's definitely something with Philips implementation of the DLNA browser that doesn't agree with the DLNA server in Emby. This thread is 8 years old, i don't know if it will ever be fixed really.
meelis 0 Posted March 11, 2024 Posted March 11, 2024 1 hour ago, le_hades said: No, It isn't solved or at least I haven't heard anything about it. There's definitely something with Philips implementation of the DLNA browser that doesn't agree with the DLNA server in Emby. This thread is 8 years old, i don't know if it will ever be fixed really. In 8 years no action to solve the problem and they wont mention it nowhere before buying it. Seems like Reddit topic for warning can be reasonable.
le_hades 4 Posted March 12, 2024 Posted March 12, 2024 (edited) 12 hours ago, meelis said: In 8 years no action to solve the problem and they wont mention it nowhere before buying it. Seems like Reddit topic for warning can be reasonable. Both implementations work well on their own, it's simply a weird bug when using a philips smart tv as client for an emby server. Personally i'm choosing not to complain... I'm not paying for the software nor the support (i'm not a premiere user) so all i can do meanwhile is wait and use another software as my DLNA server. If and when this gets fixed I would love to use Emby but right now it's a non-starter with my setup: tough luck. Edited March 12, 2024 by le_hades
meelis 0 Posted March 12, 2024 Posted March 12, 2024 I normally buy license when good SW and supporting product. In the beginning was all super untill i found out that Philips TV not supported. Most wierd is that in 8 years nothing has been done to solve it.
Luke 42077 Posted March 12, 2024 Posted March 12, 2024 7 hours ago, meelis said: I normally buy license when good SW and supporting product. In the beginning was all super untill i found out that Philips TV not supported. Most wierd is that in 8 years nothing has been done to solve it. Hi, one issue has been availability of Philips android tv's in the US. They don't sell them here.
meelis 0 Posted March 14, 2024 Posted March 14, 2024 World is a bit bigger than just US. It would be nice to support Philips TV's. Is there any hope to get it working with Philips TV's or hoplsess to wait for it? As i see in 8 years nothing has happent.
le_hades 4 Posted November 30, 2024 Posted November 30, 2024 Pinging back... @Lukeis there any work done on the new releases related to this DLNA/Philips issue? should I try them?
Luke 42077 Posted November 30, 2024 Posted November 30, 2024 3 minutes ago, le_hades said: Pinging back... @Lukeis there any work done on the new releases related to this DLNA/Philips issue? should I try them? Hi, there has been a lot of general dlna development, so yes, it's worth re-evaluating. Thanks.
le_hades 4 Posted March 24, 2025 Posted March 24, 2025 No luck, everything behaves the same as last time: The DLNA server is detected on the network. DLNA content is not browsable: the TV just displays a scrolling circle animation on the screen. 1
mascc 1 Posted May 15, 2025 Posted May 15, 2025 Hello, I have found this thread because my 49PUS6501/12 (german/eu) with Android TV does the same. The DLNA browser loads indefinitely when clicking on the emby DLNA server. Gerbera and the Fritz!Box Media Server work fine. The User-Agent the TV reports is "Linux2.6/0.0 UPnP/1.0 PhilipsIntelSDK/1.4 DLNADOC/1.50". The DLNA log looks like this (strange, the log parts have 10 minutes in between the connection and the DLNA session creation. (Or they were different sessions and some loglines got lost). Spoiler 2025-05-15 17:35:55.567 Info DLNA: Using default profile for: DeviceDescription: FriendlyName:TVNAME Manufacturer:Philips ManufacturerUrl:http://www.philips.com ModelDescription:UPnP Media Renderer 1.0 ModelName:Philips TV DMR ModelNumber:2k16MTK ModelUrl:http://www.philips.com/ SerialNumber:12345 2025-05-15 17:35:55.567 Info HttpClient: GET http://192.168.188.46:49153/nmrConnectionManager.xml 2025-05-15 17:35:55.636 Info DLNA: Device GetProtocolInfoResponse Source: 2025-05-15 17:35:55.636 Info DLNA: Device GetProtocolInfoResponse Sink: http-get:*:audio/mpeg:DLNA.ORG_PN=MP3;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMABASE;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMAFULL;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/x-ms-wma:DLNA.ORG_PN=WMAPRO;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/vnd.dlna.adts:DLNA.ORG_PN=AAC_ADTS;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=AAC_ISO;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=AAC_ISO_320;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/vnd.dlna.adts:DLNA.ORG_PN=AAC_ADTS_320;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=AAC_MULT5_ISO;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=HEAACv2_L2;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=HEAACv2_L2_320;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=HEAACv2_L3;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/mp4:DLNA.ORG_PN=HEAACv2_MULT5;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/L16;rate=44100;channels=1:DLNA.ORG_PN=LPCM;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/L16;rate=44100;channels=2:DLNA.ORG_PN=LPCM;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/L16;rate=48000;channels=1:DLNA.ORG_PN=LPCM;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:audio/L16;rate=48000;channels=2:DLNA.ORG_PN=LPCM;DLNA.ORG_FLAGS=8d700000000000000000000000000000 http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_MED http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_LRG http-get:*:image/jpeg:DLNA.ORG_PN=JPEG_SM_ICO http-get:*:video/x-ms-asf:* http-get:*:video/x-ms-asf-plugin:* http-get:*:video/avi:* http-get:*:video/x-ms-avi:* http-get:*:video/msvideo:* http-get:*:video/x-msvideo:* http-get:*:video/h264:* http-get:*:video/x-xvid:* http-get:*:video/quicktime:* http-get:*:video/webm:* http-get:*:audio/amr:* http-get:*:video/mpeg4:* http-get:*:video/x-matroska:* http-get:*:video/mpeg:* http-get:*:video/MP2T:* http-get:*:video/vnd.dlna.mpeg-tts:* http-get:*:video/mp4v-es:* http-get:*:video/mp4:* http-get:*:video/x-ms-wmv:* http-get:*:video/x-m4v:* http-get:*:video/x-m4a:* http-get:*:video/x-mkv:* http-get:*:video/x-matroska-3d:* http-get:*:video/3gpp:* http-get:*:audio/mpeg:* http-get:*:audio/x-ms-wma:* http-get:*:audio/x-ms-asf:* http-get:*:audio/L16:* http-get:*:audio/lpcm:* http-get:*:audio/wav:* http-get:*:audio/x-wav:* http-get:*:audio/x-aiff:* http-get:*:audio/mp4:* http-get:*:audio/x-aac:* http-get:*:audio/aac:* http-get:*:audio/x-mpegurl:* http-get:*:audio/amr:* http-get:*:audio/3gpp:* http-get:*:audio/3gpp2:* http-get:*:audio/vnd.dolby.dd-raw:* http-get:*:audio/vnd-dts:* http-get:*:audio/x-m4a:* http-get:*:audio/x-flac:* http-get:*:audio/flac:* http-get:*:audio/ogg:* http-get:*:audio/vorbis:* http-get:*:audio/vorbis-config:* http-get:*:image/png:DLNA.ORG_PN=PNG_LRG http-get:*:image/png:DLNA.ORG_PN=PNG_TN http-get:*:image/png:DLNA.ORG_PN=PNG_SM_ICO http-get:*:image/png:DLNA.ORG_PN=PNG_LRG_ICO http-get:*:image/bmp:DLNA.ORG_OP=01;DLNA.ORG_FLAGS=00F00000000000000000000000000000 http-get:*:text/plain:* http-get:*:text/x-microdvd:* http-get:*:application/x-subrip:* http-get:*:application/x-sami:* 2025-05-15 17:45:20.385 Info DLNA: DLNA Session created for TVNAME - Philips TV DMR. Description url: http://192.168.188.46:49153/nmrDescription.xml 2025-05-15 17:45:20.884 Info HttpClient: GET http://192.168.188.46:49153/nmrAVTransport.xml I have a slight technical background and would like to help you analyse and test this issue. Please tell me how to proceed.
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now