Philips TV not appearing in the device list and no DLNA access

[MikFlix 1]

Same behaviour on my Philips 65OLED807/12. Endless loading circle.
It works normal on my 300€ Hisense TV.

[Luke 37008]

Please try the Emby DLNA plugin update version 1.1.4+ and let me know how that compares. Thanks !

[le_hades 3]

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 37008]

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 3]

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 37008]

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 3]

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 37008]

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 3]

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 37008]

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 3]

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.

[le_hades 3]

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

[le_hades 3]

Hey @Luke¿did you had the chance to look further into this issue?

No pressure, just checking.

Thank you.

[le_hades 3]

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.

[meelis 0]

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 3]

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]

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 3]

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 by le_hades

[meelis 0]

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 37008]

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]

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.