Tvheadend

Provide '--trace satip,httpc' . https://tvheadend.org/projects/tvheadend/wiki/Traces

The Telestar Digibit Twin works with DVB Link fine.

It's irrelevant information. Provide logs as requested.

The Telestar Digibit Twin is working in TvHeadend when providing http://<Digibit Twin IP>:38400/description.xml to tvheadend using --satip_xml.

I think it's not showing up in TVAdapter List as the device lacks UPNP Support.

Hey Dominik,
I can`t understand what I have to do!?

Sorry for the bad formats.

This ain't a bug. Therefore your case can get closed by the team.

For configuration reference: https://www.tvheadend.org/boards/5/topics/14189

The --satip_xml argument is only a workaround. The device should be autodiscovered using UPnP. Again, please, show me the logs (traces) as requested in comment 1 for further analysis.

The --satip_xml argument is the only working solution as the device is not speaking UPnP.
It currently won't and maybe never will be found using UPnP.

It's fine with DVB Link, as Justus said, because you are able to add the device manually.

When I have time I will sniff the tivizen apps network traffic because it was working out of the box as far as i remember.

It seems that the server responds on UPnP 'MSEARCH *':

2016-11-10 17:38:40.432 [  TRACE]:upnp: unicast - received data from 192.168.1.29:64486 [size=333]
2016-11-10 17:38:40.432 [  TRACE]:upnp: 48 54 54 50 2F 31 2E 31 20 32 30 30 20 4F 4B 0D HTTP/1.1 200 OK.
2016-11-10 17:38:40.432 [  TRACE]:upnp: 0A 43 61 63 68 65 2D 43 6F 6E 74 72 6F 6C 3A 20 .Cache-Control: 
2016-11-10 17:38:40.432 [  TRACE]:upnp: 6D 61 78 2D 61 67 65 3D 31 38 30 30 0D 0A 44 61 max-age=1800..Da
2016-11-10 17:38:40.432 [  TRACE]:upnp: 74 65 3A 20 54 68 75 2C 20 30 31 20 4A 61 6E 20 te: Thu, 01 Jan 
2016-11-10 17:38:40.432 [  TRACE]:upnp: 31 39 37 30 20 32 33 3A 35 36 3A 33 36 20 47 4D 1970 23:56:36 GM
2016-11-10 17:38:40.432 [  TRACE]:upnp: 54 0D 0A 53 54 3A 20 75 72 6E 3A 73 65 73 2D 63 T..ST: urn:ses-c
2016-11-10 17:38:40.432 [  TRACE]:upnp: 6F 6D 3A 64 65 76 69 63 65 3A 53 61 74 49 50 53 om:device:SatIPS
2016-11-10 17:38:40.432 [  TRACE]:upnp: 65 72 76 65 72 3A 31 0D 0A 45 58 54 3A 20 0D 0A erver:1..EXT: ..
2016-11-10 17:38:40.432 [  TRACE]:upnp: 53 45 52 56 45 52 3A 20 50 6C 61 74 66 6F 72 6D SERVER: Platform
2016-11-10 17:38:40.432 [  TRACE]:upnp: 2F 31 2E 30 20 65 43 6F 73 2F 32 2E 30 33 33 54 /1.0 eCos/2.033T
2016-11-10 17:38:40.432 [  TRACE]:upnp: 20 55 50 6E 50 2F 31 2E 30 20 44 4C 4E 41 44 4F  UPnP/1.0 DLNADO
2016-11-10 17:38:40.432 [  TRACE]:upnp: 43 2F 31 2E 35 30 20 50 52 4F 44 55 43 54 2F 31 C/1.50 PRODUCT/1
2016-11-10 17:38:40.432 [  TRACE]:upnp: 2E 30 0D 0A 55 53 4E 3A 20 75 75 69 64 3A 32 31 .0..USN: uuid:21
2016-11-10 17:38:40.432 [  TRACE]:upnp: 62 39 38 61 31 30 2D 31 64 64 32 2D 31 31 62 32 b98a10-1dd2-11b2
2016-11-10 17:38:40.432 [  TRACE]:upnp: 2D 38 30 65 62 2D 65 31 30 38 36 65 62 32 31 30 -80eb-e1086eb210
2016-11-10 17:38:40.432 [  TRACE]:upnp: 65 61 3A 3A 75 72 6E 3A 73 65 73 2D 63 6F 6D 3A ea::urn:ses-com:
2016-11-10 17:38:40.432 [  TRACE]:upnp: 64 65 76 69 63 65 3A 53 61 74 49 50 53 65 72 76 device:SatIPServ
2016-11-10 17:38:40.432 [  TRACE]:upnp: 65 72 3A 31 0D 0A 4C 4F 43 41 54 49 4F 4E 3A 20 er:1..LOCATION: 
2016-11-10 17:38:40.432 [  TRACE]:upnp: 68 74 74 70 3A 2F 2F 31 39 32 2E 31 36 38 2E 31 http://192.168.1
2016-11-10 17:38:40.432 [  TRACE]:upnp: 2E 32 39 3A 33 38 34 30 30 2F 64 65 73 63 72 69 .29:38400/descri
2016-11-10 17:38:40.433 [  TRACE]:upnp: 70 74 69 6F 6E 2E 78 6D 6C 0D 0A 0D 0A          ption.xml....   

It violates SAT>IP specification. There are missing 'BOOTID.UPNP.ORG' and 'CONFIGID.UPNP.ORG'. Could you try this patch for a test ?

diff --git a/src/input/mpegts/satip/satip.c b/src/input/mpegts/satip/satip.c
index 6f44923..e671ac3 100644
--- a/src/input/mpegts/satip/satip.c
+++ b/src/input/mpegts/satip/satip.c
@@ -1116,8 +1116,10 @@ satip_discovery_service_received
     goto add_uuid;
   if (location == NULL || strncmp(location, "http://", 7))
     goto add_uuid;
+#if 0
   if (bootid == NULL || configid == NULL || server == NULL)
     goto add_uuid;
+#endif

   /* Forward information to next layer */

@@ -1131,9 +1133,9 @@ satip_discovery_service_received
   d->location = strdup(location);
   d->server   = strdup(server);
   d->uuid     = strdup(uuid);
-  d->bootid   = strdup(bootid);
-  d->configid = strdup(configid);
-  d->deviceid = strdup(deviceid ? deviceid : "");
+  d->bootid   = strdup(bootid ?: "");
+  d->configid = strdup(configid ?: "");
+  d->deviceid = strdup(deviceid ?: "");
   if (urlparse(d->location, &d->url)) {
     satip_discovery_destroy(d, 0);
     return;

looks working reporting from a user (he has no experience in Tvh so nothing more then this pic atm)

With this patch the Twin is reported as fully working, any logs or something you need to merge this ?

Is the fix integrated in the CentOS repository packages? I have the initial situation as the original poster. With the workaround (option --satip_xml http://digibit:38400/description.xml in tvheadend sysconfig file) it works. However this is not the preferred solution as I've understood and also on every update (current version is 4.2.3) the sysconfig file is overwritten and so the Digibit Twin disappears from the configuration.

Enable UDP port 1900 in your firewall (UPnP).

Thanks for the hint. It's indeed a firewall issue. It's not only UDP port 1900 because the tuner is still not found just by opening it. But lowering down the firewall results in finding the Digibit Twin - Tvheadend does the job. Now I can investigate which ports are additionally needed.