ssdp not working right (Fixed ?) about satpi HOT 25 CLOSED

Ok.. which line is this? line 174 is not there

from satpi.

sorry line 79

from satpi.

Why should it be like that?

from satpi.

without DVBviewer did not autodetect the server

have a look at http://www.satip.info/sites/satip/files/resource/satip_specification_version_1_2_2.pdf

quote

Server A sends a unicast M-SEARCH message directly to the IP address of server B: Port 1900
M-SEARCH * HTTP/1.1
HOST: 192.168.178.21:1900
MAN: "ssdp:discover"
ST: urn:ses-com:device:SatIPServer:1 USER-AGENT: Linux/1.0 UPnP/1.1 IDL4K/1.0 DEVICEID.SES.COM: 1

from satpi.

Yes... M-SEARCH.. this is NOTIFY.. I think the problem is that this uses DEVICEID.SES.COM: 1
and your other SAT>IP server is using this also...
I do not do an M-SEARCH at the moment

from satpi.

right and seems to make issues to have double DEVICEID's on the net

from satpi.

SATPI may need on time to sent ST: urn:ses-com:device:SatIPServer:1

without clients may not accept the server, you can verify this with the android signal app

from satpi.

Your right.

from satpi.

Hi 9000h

If you feel like trying and have the time you try the last commit regarding the SSDP.
It is not finished but I was wondering if it works with your 'hardware' SAT>IP server regarding the negotiation of the device id.

Thanks in advance,

Marc

from satpi.

will do, but I need to catch all ssdp traffic via tcpdump

from satpi.

the ssdp is may still not working right, my Panasonic will find the server only if I restart satpi.

from satpi.

for the negotiation of the device id, the digibit r1 may not respect the the spec
for M-SEARCH it reply's with

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Fri Feb 6 21:07:15 2015
EXT:
LOCATION: http://192.168.179.220:8080/desc.xml
SERVER: Linux/1.0 UPnP/1.1 IDL4K/1.0
ST: urn:ses-com:device:SatIPServer:1
USN: uuid:94c57fce-9096-4b9e-be24-7581170a9945::urn:ses-com:device:SatIPServer:1
BOOTID.UPNP.ORG: 65
CONFIGID.UPNP.ORG: 0

so there is no DEVICEID in, but anyway I did ordered a octonet which should act as specified and then we will see what's happen

from satpi.

Not sure if this is linked to this issue, but TVH does not recognize my SATPI instance.

But, the good news is that I was able to get DVB-C working out of the box. In order to workarround the SSDP discovery issue I had to:

• Run minisatip to get the IP registred in TVH
• Kill minisatip and start satpi instead

And voila

For those tests I used TVH 3.9.2497 (from unstable branch)
Here is what I see in satpi log (I see nothing in TVH):
81  Sun Feb 15 21:58:24.248378674 2015  6  SAT>IP Client 192.168.1.20 : tries to discover the network, sending an reply fd: 25
82  Sun Feb 15 21:58:24.248538276 2015  6  SAT>IP Client 192.168.1.20 : tries to discover the network, sending an reply fd: 25
83  Sun Feb 15 21:58:24.248594596 2015  6  SAT>IP Client 192.168.1.20 : tries to discover the network, sending an reply fd: 25

SATPI & TVH are my only SAT>IP client & server on the network

from satpi.

Hi FuNK3Y,

Thanks for testing. Just a quick question:

• how did you start TVH ?

Marc

from satpi.

I just restarted the service:
service tvheadend restart

from satpi.

Hi,

So nothing special to make SAT>IP work in TVH?

from satpi.

From my limited experience with SAT>IP no (as long as you are running a recent version of tvheadend). I tested with minisatip and the SAT>IP tuner just got displayed under the tuners, like a physical connected one would do.

But as far as I can remember, I was unable to get DVB Viewer lite to discover my SATPI instance as well.

from satpi.

Mmm... ok thanks for testing but SatPI is sending some message back to IP 192.168.1.20
which is I think TVH. But probably it did not like it..
I will look at it some more.
I start TVH with --satip-xml or something.

Marc

from satpi.

Yes that is correct, 192.168.1.20 is the IP of my tvheadend.

I will give a try with the --satip_xml parameter later today. But your analysis seems to be the correct one as everything but the discovery works, TVH most certainly doesn't like the answer from SATPI

from satpi.

With the --satip_xml it works fine.

from satpi.

Hi,

Yes I use it like this for Historical reason. I should update my TVH on synology and try it without.
thanks for pointing this out,

Marc

from satpi.

my octonet is here but it runs not stable, as soon DD has fixed the firmware I will give it a try

from satpi.

Hi,

Is this issue is fixed with latest commits?

Marc

from satpi.

From my perspective yes, it works fine with the latest releases

from satpi.

Ok.. I think this can close now.

from satpi.