LG BD645 can not discover Serviio

I am a newbie so please bear with me.
I just bought a LG LW5300 bundle with a LG BD645 blueray player. I set it up for wired networked and serviio discovered it as a Generic Player. I've been using Serviio with my Samsung DLNA TV with no issues. But on the BD645 side, it just won't discover the Serviio server and kept on saying "No Network Devices".

Do I need a special profile for the Blueray player? Can somebody please cut and paste a profile for me for LG BD players?

I started to wonder if it's a firmware issue on the BD player side.

Please help. Thanks in advance.

[zip]

there is a LG BD profile already, but it wont help you with discovery. Give the player a static IP on the router and make sure its on the same subnetwork (the first 3 parts of the IP are the same as the machine running Serviio)

Hi Zip,

Both the server and the player are on the same subnet with the same subnet mask and the IPs are statically reserved on the router. I wonder if there is particular ports I need to open up on the Serviio server side to accommodate LG players; I did not need to do that for the Samsung DLNA TV I had.

I will do a WireShark capture during the discovery. Can you please tell me what's the listening port on the serviio side I should use to filter the capture result?

Thanks,

Yang

[zip]

TCP 8895, UDP 1900. You can check detailed serviio log as well if there is any traffic from your player IP. Is the player definitely DLNA compatible?

Hi Zip,

Here is the serviio log handshaking portion:
2011-12-21 23:07:49,483 DEBUG [OnlineRepositoryDAOImpl] Reading all OnlineRepositories
2011-12-21 23:07:55,788 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target ssdp:all from address /192.168.0.108:59000
2011-12-21 23:07:55,790 DEBUG [DiscoverySearchResponder] Sending 6 M-SEARCH response message(s) to /192.168.0.108:59000
2011-12-21 23:07:55,792 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target ssdp:all from address /192.168.0.108:59000
2011-12-21 23:07:55,792 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target ssdp:all from address /192.168.0.108:59000
2011-12-21 23:07:55,794 DEBUG [DiscoverySearchResponder] Sending 6 M-SEARCH response message(s) to /192.168.0.108:59000
2011-12-21 23:07:55,794 DEBUG [DiscoverySearchResponder] Sending 6 M-SEARCH response message(s) to /192.168.0.108:59000
2011-12-21 23:07:55,828 DEBUG [WebServer] Incoming connection from /192.168.0.108:45517
2011-12-21 23:07:55,829 DEBUG [WebServer] Incoming connection from /192.168.0.108:45518
2011-12-21 23:07:55,829 DEBUG [ServiceEventSubscriptionRequestHandler] ServiceEvent renewal request received for service ConnectionManager and subscription uuid:586e91fd-a789-4632-8105-3c363213e180
2011-12-21 23:07:55,830 DEBUG [ServiceEventSubscriptionRequestHandler] Event subscription renewed for service urn:upnp-org:serviceId:ConnectionManager and subscription 586e91fd-a789-4632-8105-3c363213e180
2011-12-21 23:07:55,830 DEBUG [WebServer] Incoming connection from /192.168.0.108:45519
2011-12-21 23:07:55,830 DEBUG [ServiceEventSubscriptionRequestHandler] ServiceEvent renewal request received for service X_MS_MediaReceiverRegistrar and subscription uuid:64ff73b8-6fa0-4969-ad82-66d6f17f7e96
2011-12-21 23:07:55,830 DEBUG [ServiceEventSubscriptionRequestHandler] Event subscription renewed for service urn:microsoft.com:serviceId:X_MS_MediaReceiverRegistrar and subscription 64ff73b8-6fa0-4969-ad82-66d6f17f7e96
2011-12-21 23:07:55,831 DEBUG [ServiceEventSubscriptionRequestHandler] ServiceEvent renewal request received for service ContentDirectory and subscription uuid:74411903-7bc3-4a58-97f1-a27358888765
2011-12-21 23:07:55,831 DEBUG [ServiceEventSubscriptionRequestHandler] Event subscription renewed for service urn:upnp-org:serviceId:ContentDirectory and subscription 74411903-7bc3-4a58-97f1-a27358888765
2011-12-21 23:08:16,689 DEBUG [DiscoveryAdvertisementNotifier] Multicasting SSDP alive using interface eth3 (Realtek PCIe FE Family Controller) and address 192.168.0.107, timeout = 0
2011-12-21 23:08:16,689 DEBUG [DiscoveryAdvertisementNotifier] Sending 6 'alive' messages describing device bc843b93-c84a-3dc3-b5ea-d8857c5e8b19
2011-12-21 23:08:18,546 DEBUG [DiscoveryAdvertisementNotifier] Will advertise again in 00:01:25
2011-12-21 23:08:25,795 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target ssdp:all from address /192.168.0.108:59000
2011-12-21 23:08:25,795 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target ssdp:all from address /192.168.0.108:59000
2011-12-21 23:08:25,796 DEBUG [DiscoverySSDPMessageListener] Received a valid M-SEARCH message for search target ssdp:all from address /192.168.0.108:59000
2011-12-21 23:08:25,797 DEBUG [DiscoverySearchResponder] Sending 6 M-SEARCH response message(s) to /192.168.0.108:59000
2011-12-21 23:08:25,798 DEBUG [DiscoverySearchResponder] Sending 6 M-SEARCH response message(s) to /192.168.0.108:59000
2011-12-21 23:08:25,798 DEBUG [DiscoverySearchResponder] Sending 6 M-SEARCH response message(s) to /192.168.0.108:59000
2011-12-21 23:08:49,484 DEBUG [OnlineRepositoryDAOImpl] Reading all OnlineRepositories

192.168.0.107 is the server and 192.168.0.108 is the BD player.

Here is the SSDP query packet pcap output from the player to the server:

  Code:

No.     Time        Source                Destination           Protocol Length Info
    520 31.123287   192.168.0.108         239.255.255.250       SSDP     136    M-SEARCH * HTTP/1.1

Frame 520: 136 bytes on wire (1088 bits), 136 bytes captured (1088 bits)
    Arrival Time: Dec 21, 2011 23:03:25.782951000 Pacific Standard Time
    Epoch Time: 1324537405.782951000 seconds
    [Time delta from previous captured frame: 0.000039000 seconds]
    [Time delta from previous displayed frame: 0.000039000 seconds]
    [Time since reference or first frame: 31.123287000 seconds]
    Frame Number: 520
    Frame Length: 136 bytes (1088 bits)
    Capture Length: 136 bytes (1088 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:http]
    [Coloring Rule Name: HTTP]
    [Coloring Rule String: http || tcp.port == 80]
Ethernet II, Src: AyecomTe_3c:ff:02 (00:1a:2b:3c:ff:02), Dst: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)
    Destination: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)
        Address: IPv4mcast_7f:ff:fa (01:00:5e:7f:ff:fa)
        .... ...1 .... .... .... .... = IG bit: Group address (multicast/broadcast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: AyecomTe_3c:ff:02 (00:1a:2b:3c:ff:02)
        Address: AyecomTe_3c:ff:02 (00:1a:2b:3c:ff:02)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.0.108 (192.168.0.108), Dst: 239.255.255.250 (239.255.255.250)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 122
    Identification: 0x0000 (0)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 1
    Protocol: UDP (17)
    Header checksum: 0xc864 [correct]
        [Good: True]
        [Bad: False]
    Source: 192.168.0.108 (192.168.0.108)
    Destination: 239.255.255.250 (239.255.255.250)
User Datagram Protocol, Src Port: 59000 (59000), Dst Port: ssdp (1900)
    Source port: 59000 (59000)
    Destination port: ssdp (1900)
    Length: 102
    Checksum: 0x1480 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Hypertext Transfer Protocol
    M-SEARCH * HTTP/1.1\r\n
        [Expert Info (Chat/Sequence): M-SEARCH * HTTP/1.1\r\n]
            [Message: M-SEARCH * HTTP/1.1\r\n]
            [Severity level: Chat]
            [Group: Sequence]
        Request Method: M-SEARCH
        Request URI: *
        Request Version: HTTP/1.1
    HOST: 239.255.255.250:1900\r\n
    MAN: "ssdp:discover"\r\n
    MX: 3\r\n
    ST: ssdp:all\r\n
    \r\n
    [Full request URI: http://239.255.255.250:1900*]

0000  01 00 5e 7f ff fa 00 1a 2b 3c ff 02 08 00 45 00   ..^.....+<....E.
0010  00 7a 00 00 40 00 01 11 c8 64 c0 a8 00 6c ef ff   .z..@....d...l..
0020  ff fa e6 78 07 6c 00 66 14 80 4d 2d 53 45 41 52   ...x.l.f..M-SEAR
0030  43 48 20 2a 20 48 54 54 50 2f 31 2e 31 0d 0a 48   CH * HTTP/1.1..H
0040  4f 53 54 3a 20 32 33 39 2e 32 35 35 2e 32 35 35   OST: 239.255.255
0050  2e 32 35 30 3a 31 39 30 30 0d 0a 4d 41 4e 3a 20   .250:1900..MAN:
0060  22 73 73 64 70 3a 64 69 73 63 6f 76 65 72 22 0d   "ssdp:discover".
0070  0a 4d 58 3a 20 33 0d 0a 53 54 3a 20 73 73 64 70   .MX: 3..ST: ssdp
0080  3a 61 6c 6c 0d 0a 0d 0a                           :all....


Here is the response from the server to the BD Player and afterwards the serviio server kept on sending the same packet and does not seem to get an ack:

  Code:

No.     Time        Source                Destination           Protocol Length Info
    522 31.123874   192.168.0.107         192.168.0.108         UDP      381    Source port: 55789  Destination port: 59000

Frame 522: 381 bytes on wire (3048 bits), 381 bytes captured (3048 bits)
    Arrival Time: Dec 21, 2011 23:03:25.783538000 Pacific Standard Time
    Epoch Time: 1324537405.783538000 seconds
    [Time delta from previous captured frame: 0.000585000 seconds]
    [Time delta from previous displayed frame: 0.000585000 seconds]
    [Time since reference or first frame: 31.123874000 seconds]
    Frame Number: 522
    Frame Length: 381 bytes (3048 bits)
    Capture Length: 381 bytes (3048 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ip:udp:data]
    [Coloring Rule Name: Checksum Errors]
    [Coloring Rule String: cdp.checksum_bad==1 || edp.checksum_bad==1 || ip.checksum_bad==1 || tcp.checksum_bad==1 || udp.checksum_bad==1 || sctp.checksum_bad==1 || mstp.checksum_bad==1]
Ethernet II, Src: Micro-St_cd:f2:d6 (6c:62:6d:cd:f2:d6), Dst: AyecomTe_3c:ff:02 (00:1a:2b:3c:ff:02)
    Destination: AyecomTe_3c:ff:02 (00:1a:2b:3c:ff:02)
        Address: AyecomTe_3c:ff:02 (00:1a:2b:3c:ff:02)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Source: Micro-St_cd:f2:d6 (6c:62:6d:cd:f2:d6)
        Address: Micro-St_cd:f2:d6 (6c:62:6d:cd:f2:d6)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
    Type: IP (0x0800)
Internet Protocol Version 4, Src: 192.168.0.107 (192.168.0.107), Dst: 192.168.0.108 (192.168.0.108)
    Version: 4
    Header length: 20 bytes
    Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00: Not-ECT (Not ECN-Capable Transport))
        0000 00.. = Differentiated Services Codepoint: Default (0x00)
        .... ..00 = Explicit Congestion Notification: Not-ECT (Not ECN-Capable Transport) (0x00)
    Total Length: 367
    Identification: 0x53d3 (21459)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0x0000 [incorrect, should be 0x6383 (maybe caused by "IP checksum offload"?)]
        [Good: False]
        [Bad: True]
            [Expert Info (Error/Checksum): Bad checksum]
                [Message: Bad checksum]
                [Severity level: Error]
                [Group: Checksum]
    Source: 192.168.0.107 (192.168.0.107)
    Destination: 192.168.0.108 (192.168.0.108)
User Datagram Protocol, Src Port: 55789 (55789), Dst Port: 59000 (59000)
    Source port: 55789 (55789)
    Destination port: 59000 (59000)
    Length: 347
    Checksum: 0x8394 [validation disabled]
        [Good Checksum: False]
        [Bad Checksum: False]
Data (339 bytes)
    Data: 485454502f312e3120323030204f4b0d0a43414348452d43...
    [Length: 339]

0000  00 1a 2b 3c ff 02 6c 62 6d cd f2 d6 08 00 45 00   ..+<..lbm.....E.
0010  01 6f 53 d3 00 00 80 11 00 00 c0 a8 00 6b c0 a8   .oS..........k..
0020  00 6c d9 ed e6 78 01 5b 83 94 48 54 54 50 2f 31   .l...x.[..HTTP/1
0030  2e 31 20 32 30 30 20 4f 4b 0d 0a 43 41 43 48 45   .1 200 OK..CACHE
0040  2d 43 4f 4e 54 52 4f 4c 3a 20 6d 61 78 2d 61 67   -CONTROL: max-ag
0050  65 20 3d 20 31 38 30 0d 0a 4c 4f 43 41 54 49 4f   e = 180..LOCATIO
0060  4e 3a 20 68 74 74 70 3a 2f 2f 31 39 32 2e 31 36   N: http://192.16
0070  38 2e 30 2e 31 30 37 3a 38 38 39 35 2f 64 65 76   8.0.107:8895/dev
0080  69 63 65 44 65 73 63 72 69 70 74 69 6f 6e 2f 62   iceDescription/b
0090  63 38 34 33 62 39 33 2d 63 38 34 61 2d 33 64 63   c843b93-c84a-3dc
00a0  33 2d 62 35 65 61 2d 64 38 38 35 37 63 35 65 38   3-b5ea-d8857c5e8
00b0  62 31 39 0d 0a 45 58 54 3a 20 0d 0a 44 41 54 45   b19..EXT: ..DATE
00c0  3a 20 54 68 75 2c 20 32 32 20 44 65 63 20 32 30   : Thu, 22 Dec 20
00d0  31 31 20 30 37 3a 30 33 3a 32 35 20 47 4d 54 0d   11 07:03:25 GMT.
00e0  0a 53 45 52 56 45 52 3a 20 57 69 6e 64 6f 77 73   .SERVER: Windows
00f0  20 37 2c 20 55 50 6e 50 2f 31 2e 30 20 44 4c 4e    7, UPnP/1.0 DLN
0100  41 44 4f 43 2f 31 2e 35 30 2c 20 53 65 72 76 69   ADOC/1.50, Servi
0110  69 6f 2f 30 2e 36 2e 30 2e 31 0d 0a 53 54 3a 20   io/0.6.0.1..ST:
0120  75 75 69 64 3a 62 63 38 34 33 62 39 33 2d 63 38   uuid:bc843b93-c8
0130  34 61 2d 33 64 63 33 2d 62 35 65 61 2d 64 38 38   4a-3dc3-b5ea-d88
0140  35 37 63 35 65 38 62 31 39 0d 0a 55 53 4e 3a 20   57c5e8b19..USN:
0150  75 75 69 64 3a 62 63 38 34 33 62 39 33 2d 63 38   uuid:bc843b93-c8
0160  34 61 2d 33 64 63 33 2d 62 35 65 61 2d 64 38 38   4a-3dc3-b5ea-d88
0170  35 37 63 35 65 38 62 31 39 0d 0a 0d 0a            57c5e8b19....



[zip]

so the first bit seems to be working - the server receives M-SEARCH from the player and responds with the URL of its description. Then the player should request this description document, on TCP 8895. make sure that is open. It might be in your log further down. If it's not the player cannot connect to get the description.

Hi Zip,

Is there a way I can email you the wireshack PCAP file directly please? I just can't figure this one out. LG support is useless. I tried numerous DLNA servers and none seems to be working with this BD player.

Thanks

[zip]

Can you install Intel tools and check Serviio shows in DeviceSpy? Then you could do the same on another PC (if you have one) on the network.

Zip,

Do you mean to install "intel tool" on the Blueray player? I would like to have more details about the "intel tools" you are referring to? I tried DLNA playback from another PC in the same network with the same Serviio server I've set up and it worked perfectly. So I think it is definitely something wrong with the LG Blueray player but I just don't know why.

Thanks.

[Cerberus]

Zip,

Do you mean to install "intel tool" on the Blueray player? I would like to have more details about the "intel tools" you are referring to? I tried DLNA playback from another PC in the same network with the same Serviio server I've set up and it worked perfectly. So I think it is definitely something wrong with the LG Blueray player but I just don't know why.

Thanks.

no intel tools is installed on a Pc rather than your renderer (the BDP)

http://opentools.homeip.net/dev-tools-for-upnp

[NX3]

viewtopic.php?f=5&t=19