Tvheadend

BTW with minisatip there was no problem at all. Neither with channel searching nor with signal receiving.

Could you do the network dump for the Panasonic's IP for both minisatip and tvh to compare on the server? I don't see any issue in logs (tcpdump -s 2048 -w pan.tcpdump ip host your_panasonic_ip).

I setup an environment for qtcreator to debug tvheadend and find the reason for not getting any channels to the TV. For some reason it did found the channels immediately (as one time before, configuration is the same, so I don't know what has changed).

After the channel search, watching TV works so far. But if I power off the TV and power it on, the TV is not able to reconnect to TVH. When I restart TVH it reconnects automatically. So it seems like the SatIP Server implementation is not properly cleaning up previous connections.

I setup an environment for qtcreator with the intention to debug tvheadend and find the reason for not getting any channels to the TV. For some reason it did found the channels immediately (as one time before, configuration is the same, so I don't know what has changed).

After the channel search, watching TV works so far. But if I power off the TV and power it on again, the TV is not able to reconnect to TVH (server not found). When I restart TVH and let the TV on, it reconnects automatically.
The same problem exists, if I start TVH before powering on the TV. So for a working connection, I need to power on the TV and then restart TVH.

Than it looks like an UPnP problem. It would be good to identify working / non-working packets on UDP port 1900 .

I think that TV ignores the PnP answers from TVH for a reason.

--- received from TV ---
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: "ssdp:discover" 
MX: 1
ST: urn:ses-com:device:SatIPServer:1
NT: urn:panasonic-com:service:p00ProAVControlService:1
NTS: ssdp:alive
SERVER: FreeBSD/8.0 UPnP/1.0 Panasonic-MIL-DLNA-SV/1.0
USN: uuid:4D454930-0300-1000-8001-20C6EBEAA109::urn:panasonic-com:service:p00ProAVControlService:1

--- answer from TVH ---
HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
EXT:
LOCATION: http://192.168.178.23:9981/satip_server/desc.xml
SERVER: unix/1.0 UPnP/1.1 TVHeadend/4.1-361~gd9cf931-dirty
ST: urn:ses-com:device:SatIPServer:1
USN: uuid:10d2b31e-abf1-9753-366c-07233c6f::urn:ses-com:device:SatIPServer:1
BOOTID.UPNP.ORG: 1438549371
CONFIGID.UPNP.ORG: 0

Anwer from minisatip:

HTTP/1.1 200 OK
CACHE-CONTROL: max-age=1800
DATE: Mon, Aug 3 07:32:54 2015 GMT
EXT:
LOCATION: http://192.168.100.237:8080/desc.xml
SERVER: Linux/1.0 UPnP/1.1 minisatip/0.1.84
ST: urn:ses-com:device:SatIPServer:1
USN: uuid:11223344-9999-0000-b7ae-0022b7f0056e::urn:ses-com:device:SatIPServer:1
BOOTID.UPNP.ORG: 3
CONFIGID.UPNP.ORG: 0
DEVICEID.SES.COM: 2

The DEVICEID.SES.COM header is optional as per SAT>IP spec, maybe it may be missing DATE or character ~ in tvh version (SERVER header)...

I also fixed the uuid length in v4.1-362-gaf270b6 - just remove the satip_uuid line from <config_dir>/config file to create a new one or add four random hexa characters at the end of this string.

Thanks for your help. Unfortunately none of those changes did help. But the UPNP hint and the SATIP specification did help me finding a solution. In the spec it is mentioned:

Multicast NOTIFY ssdp:alive messages are sent regularly by all SAT>IP servers in order to signal their presence

So all one has to do is to add a single line:

diff --git src/satip/server.c src/satip/server.c
index bcb9507..6bbfc30 100644
--- src/satip/server.c
+++ src/satip/server.c
@@ -476,7 +476,8 @@ satips_upnp_discovery_received
       satips_upnp_send_discover_reply(storage, NULL);
     }
   } else {
-    satips_upnp_send_discover_reply(storage, NULL);
+      satips_upnp_send_announce();
+      satips_upnp_send_discover_reply(storage, NULL);
   }
 }

Hm,... even if it works now when debugging. For some reason if I start it as a service, channel searching and watching is still not working. For some reason when I start it from the terminal without -f -u root -g video it works. But it seems as soon as I daemonize it, does not work anymore. But it seems to be a different reason. I can see in the logs, that subscription to channels seem to work, but there seem to be no data send to the TV.

Any hint?

I will do some network logging this evening.

And another bug seems to be that if I enable epggrab for the DVB-S2 card, sometimes it blocks the TV from using the card.
At least that's the way I interpret this message during TV's channel search:

[INFO] subscription: 001B: "epggrab" subscribing to mux "10847V", weight: 4, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription" 
[ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 

One addition to the epggrab problem. It seems like this happens everytime when there is an error during scanning a channel. Sometimes it happens that I get a message "scan no data, failed", "service instance is bad, reason: No input detected" and after that, the epggraber jumps in

2015-08-04 07:06:10.096 [   INFO] mpegts: 10832.25H in Astra - tuning on Montage M88DS3103 : DVB-S #0
2015-08-04 07:06:10.136 [   INFO] subscription: 0015: "SAT>IP" subscribing to mux "10832.25H", weight: 100, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription", hostname="192.168.178.47"                                                                                                                                                                                                                               
2015-08-04 07:06:22.595 [   INFO] subscription: 0015: "SAT>IP" unsubscribing, hostname="192.168.178.47" 
2015-08-04 07:06:22.645 [   INFO] mpegts: 10847V in Astra - tuning on Montage M88DS3103 : DVB-S #0
2015-08-04 07:06:22.714 [   INFO] subscription: 0018: "SAT>IP" subscribing to mux "10847V", weight: 100, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription", hostname="192.168.178.47" 
2015-08-04 07:06:25.819 [WARNING] satips: 0/D16EB5C7/2: create mux DVBS freq 10862000 H sym 22000000 fec 7/8 mod QPSK roff 35 is_id -1 pls_mode ROOT pls_code 0
2015-08-04 07:06:25.821 [   INFO] subscription: 0018: "SAT>IP" unsubscribing, hostname="192.168.178.47" 
2015-08-04 07:06:25.887 [   INFO] mpegts: 10862H in Astra - tuning on Montage M88DS3103 : DVB-S #0
2015-08-04 07:06:26.171 [   INFO] opentv-skyit: registering mux 10862H in Astra
2015-08-04 07:06:26.178 [   INFO] subscription: 0019: "SAT>IP" subscribing to mux "10862H", weight: 100, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription", hostname="192.168.178.47" 
2015-08-04 07:06:35.000 [   INFO] mpegts: 10862H in Astra - scan no data, failed
2015-08-04 07:06:36.000 [WARNING] subscription: 0019: service instance is bad, reason: No input detected
2015-08-04 07:06:37.000 [   INFO] mpegts: 10847V in Astra - tuning on Montage M88DS3103 : DVB-S #0
2015-08-04 07:06:37.068 [   INFO] subscription: 001B: "epggrab" subscribing to mux "10847V", weight: 4, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription" 
2015-08-04 07:06:39.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:41.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:43.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:45.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:47.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:49.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:51.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:53.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:55.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:57.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:06:59.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:07:01.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:07:03.000 [ NOTICE] subscription: 0019: No input source available for subscription "SAT>IP" to mux "10862H in Astra" 
2015-08-04 07:07:03.606 [   INFO] subscription: 0019: "SAT>IP" unsubscribing, hostname="192.168.178.47" 
2015-08-04 07:07:03.608 [   INFO] mpegts: 10862H in Astra (0x7f02d402ef90) - deleting
2015-08-04 07:07:03.609 [   INFO] mpegts: 10876.5V in Astra - tuning on Montage M88DS3103 : DVB-S #0
2015-08-04 07:07:03.656 [   INFO] subscription: 001B: "epggrab" unsubscribing
2015-08-04 07:07:03.662 [   INFO] subscription: 001D: "SAT>IP" subscribing to mux "10876.5V", weight: 100, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription", hostname="192.168.178.47" 
2015-08-04 07:07:06.376 [   INFO] subscription: 001D: "SAT>IP" unsubscribing, hostname="192.168.178.47" 
2015-08-04 07:07:06.435 [   INFO] mpegts: 10891.25H in Astra - tuning on Montage M88DS3103 : DVB-S #0
2015-08-04 07:07:06.912 [   INFO] subscription: 001F: "SAT>IP" subscribing to mux "10891.25H", weight: 100, adapter: "Montage M88DS3103 : DVB-S #0", network: "Astra", service: "Raw PID Subscription", hostname="192.168.178.47"                                                                                                     

Last update for the time being:

I worked around the problem with the demonizing of TVH by adding a cronjob @reboot. While testing this workaround I noticed that I had a startup job and additionally an update.rc script for TVH. Not sure if that may cause clashes, that two instances of TVH would be started (although I would have expected much more trouble, if really two processes would have been started).

But for now (not tested for a long period and in every detail yet), it seems like having the satips_upnp_send_announce(); added everything works fine.

If I have time, I will retry starting TVH in daemon mode later, but for now I'm satisfied. Maybe you can add the satips_upnp_send_announce(); fix to the official repository.

Thanks!

Unfortunately, I don't think that sending announce on each client discovery request is a good idea. Could you check, what's different for minisatip ?

I looked to the minisatip sources and I don't think that it sends the announce multicasts more than several times per hour.

Hi,
i think i have run into the same issue as volker. I tried to use the sat-ip service in combination with a panasonic cxw804 tv, and after initial scan and power toggle of the tv i am unable to tune to a channel.
Is there any work in progress for this issue?
In meantime i would like to try the mentioned workaround. But as i am pretty unexperienced in coding i am not sure how i should apply the changes.
In current source of server.c (v4.1.593) there seem to be two lines that could match. Can you point me to the right direction where i have to add the changes?

474 satips_upnp_send_discover_reply(storage, deviceid);
475 satips_upnp_send_byebye();
476 satips_upnp_send_announce();
477 } else {
478 satips_upnp_send_discover_reply(storage, NULL);
479 }
480 } else {
481 satips_upnp_send_discover_reply(storage, NULL);
482 }

As another workaround you might setup minisatip as the SATIP server and let TVHeadend use the device as satip client. This is far from optimal, but with minisatip I got no problems at all. You only have to take care that TVH is not using minisatip for epg grabbing, otherwise your TV won't be able to use the device.
This is probably only a solution if you have at least one more Sat receiver that can be used by TVH.
Unfortunately I don'thave the time to work on this problem. It already took a lot of time to find the workaround with the UPNP annonuncement and my wife does not understand why I still should spent time fixing things that already are working.
By the way, sometimes it still shows "No server found" after switching on the TV but after a few seconds it finally always works. So it probably has something to do with the UPNP annoncement, but it might not be the only issue. I'm currently thinking about buying an octupos net, this way I would use that SATIP server for the TV and keep the other receiving device for TVH

Volker, could you grab the initial network communication between TV and minisatip using tcpdump or wireshark ? Including multicasts ? Upload .pcap file here, please.

Unfortunately not immediately. I'm currently very busy, so if someone else has the possibility it will be probably a quicker solution. But if I have time and noone else provided a log, I will try to provide it.

As my wife does not like me to spend so much time with the TV instead of the kids, I switched to an octopus net device as the satip source for the panasonic. So I won't be able to provide any logs anymore.

hello volker. thats a bit pitty but understandable. In meantime i briefly tried to get minisatip running to provide the requested logs, but even wans't able to compile it on my system. If i find some more time i will resume on this.

Wolfgang - thanks. Could you also do same for TVH answers (when it does not work) ? (gather pcap file)

Could you try v4.1-830-gaeb20ca ? (upload .pcap if it does not work, thanks)

It's something I don't understand. The RTCP part is not working for a reason. Do you see anything in TVH log like 'RTCP send to error' ?

I'm sorry that i can't provide more information.
In my opinion tvHeadendn log doesn't show anything interesting

2015-11-02 21:28:43.356 mpegts: 10729V in Andere - tuning on STV090x Multistandard : DVB-S #0 (CineS2v6.5)
2015-11-02 21:28:43.860 subscription: 00D0: "SAT>IP" subscribing to mux "10729V", weight: 100, adapter: "STV090x Multistandard : DVB-S #0 (CineS2v6.5)", network: "Andere", service: "Raw PID Subscription", hostname="10.0.0.220"
2015-11-02 21:30:09.077 subscription: 00D0: "SAT>IP" unsubscribing, hostname="10.0.0.220"
2015-11-02 21:30:09.078 mpegts: 10744H in Andere - tuning on STV090x Multistandard : DVB-S #0 (CineS2v6.5)
2015-11-02 21:30:09.383 subscription: 00D1: "SAT>IP" subscribing to mux "10744H", weight: 100, adapter: "STV090x Multistandard : DVB-S #0 (CineS2v6.5)", network: "Andere", service: "Raw PID Subscription", hostname="10.0.0.220"
2015-11-02 21:30:10.437 subscription: 00D1: "SAT>IP" unsubscribing, hostname="10.0.0.220"

Thanks. Could you update to latest? v4.1-842-gac70d65

Enable 'satips' trace subsystem (compile tvh with --enable-trace) : https://tvheadend.org/projects/tvheadend/wiki/Traces

And provide the TVH trace log.

Crash is fixed in v4.1-852-gf5e0caa .

Could you do same, but after you enable the trace output, please, change the weight in SAT>IP server config by one and press save. Then do streaming. I don't see the start logs (or you cut the file).

I don't see the debug lines. Have you compiled TVH again when you applied the patch?

I tried to reproduce here, but I see all RTCP messages from the TVH server:

2015-11-06 19:27:03.589 [  TRACE]:satips: RTCP send to 192.168.1.1:19369 : ver=1.0;src=0;tuner=0,204,1,15,12525,v,dvbs,qpsk,,35,27500,34;pids=0,1,16,17,100,165,1029

You should also see 'RTCP nanosleep' lines in the log with the patch from comment number 36 .

i am pretty sure that i have applied the patch correctly. I performed a complete git clone, applied the patch as you told (checked rtp.c for changes before compiling):

while (satip_rtcp_run) {
ts.tv_sec = 0;
ts.tv_nsec = 150000000;
do {
r = nanosleep(&ts, &ts);
if (!satip_rtcp_run)
goto end;
} while (r && ts.tv_nsec);
tvhtrace("satips", "RTCP nanosleep");
pthread_mutex_lock(&satip_rtp_lock);
TAILQ_FOREACH(rtp, &satip_rtp_sessions, link) {
tvhtrace("satips", "RTCP sq = %p", rtp->sq);
if (rtp->sq == NULL) continue;
len = satip_rtcp_build(rtp, msg);
if (len <= 0) continue;
if (tvhtrace_enabled()) {

then i compiled it with following parameters "./configure --prefix=/usr --enable-bundle --enable-imagecaching --disable-avahi --disable-hdhomerun_client --disable-vdpau --enable-libffmpeg_static --enable-trace"
i am not sure what could have been gone wrong, but i will give it a new try later this evenving

BTW: Do you see the rtcp thread when you start tvheadend ?

$ ps -Ta | grep rtcp
20751 20752 pts/4    00:00:00 tvh:satip-rtcp

Could you eventually run trace on it ?

$ strace -p 20752
Process 20752 attached
restart_syscall(<... resuming interrupted call ...>) = 0
nanosleep({0, 150000000}, 0x7fe4cc695e80) = 0
nanosleep({0, 150000000}, 0x7fe4cc695e80) = 0
nanosleep({0, 150000000}, 0x7fe4cc695e80) = 0
nanosleep({0, 150000000}, 0x7fe4cc695e80) = 0
nanosleep({0, 150000000}, 0x7fe4cc695e80) = 0
nanosleep({0, 150000000}, 0x7fe4cc695e80) = 0

(Use the second number (LWP) as reported by ps).

no, i don't see this thread. Should it be running constantly, or just when tuning to a channel?

wolfi@homeserver-2015:~$ ps -Ta | grep rtcp
wolfi@homeserver-2015:~$ ps -TA | grep rtcp
wolfi@homeserver-2015:~$ ps -TA | grep tvh
4055 4055 ? 00:00:00 tvheadend
4055 4056 ? 00:00:00 tvh:log
4055 4057 ? 00:00:00 tvh:notify
4055 4058 ? 00:00:00 tvheadend
4055 4059 ? 00:00:00 tvh:tasklet
4055 4060 ? 00:00:00 tvh:fsmonitor
4055 4061 ? 00:00:00 tvh:imagecache
4055 4062 ? 00:00:00 tvh:httpc
4055 4063 ? 00:00:00 tvh:service
4055 4064 ? 00:00:00 tvh:mi-table
4055 4065 ? 00:00:00 tvh:mi-main
4055 4066 ? 00:00:00 tvh:iptv
4055 4068 ? 00:00:00 tvh:mi-table
4055 4069 ? 00:00:00 tvh:mi-main
4055 4071 ? 00:00:00 tvh:mi-table
4055 4072 ? 00:00:00 tvh:mi-main
4055 4074 ? 00:00:00 tvh:mi-table
4055 4075 ? 00:00:00 tvh:mi-main
4055 4077 ? 00:00:00 tvh:mi-table
4055 4078 ? 00:00:00 tvh:mi-main
4055 4079 ? 00:00:00 tvh:tshift-reap
4055 4080 ? 00:00:00 tvh:tcp-loop
4055 4081 ? 00:00:00 tvh:upnp
4055 4082 ? 00:00:00 tvh:svcmap
4055 4083 ? 00:00:00 tvh:cwc
4055 4085 ? 00:00:00 tvh:cwc
4055 4087 ? 00:00:00 tvh:cwc
4055 4088 ? 00:00:00 tvh:cwc
4055 4089 ? 00:00:00 tvh:cwc-writer
4055 4091 ? 00:00:00 tvh:cwc-writer
4055 4092 ? 00:00:00 tvh:cwc-writer
4055 4095 ? 00:00:00 tvh:cwc-writer
4055 4106 ? 00:00:00 tvh:epggrabi
4055 4109 ? 00:00:00 tvh:dvr-inotify
4055 4149 ? 00:00:00 tvh:tcp-start
wolfi@homeserver-2015:~$

Could it be a problem that i run the applicantion through this call: "sudo /usr/bin/tvheadend -u root -g video -c /var/tvheadend_config/ -f"
I ended up usng this because i didn't find a better way to get rtsp port 554 working

okay, it seems to be a problem when i start it with the fork parameter. If have to confess that i am not absolutely aware about the impacts of this, but if i run it in the console the rtcp thread seems to start

wolfi@homeserver-2015:~$ ps -TA | grep rtcp
6557 6558 pts/0 00:00:00 tvh:satip-rtcp

Currently i have no access to the tv, i will try it later when i am back at home and tell you about it.

Thanks. A step forward. I'll look to issue with the fork usage. It's a bit suspicious. The behaviour should be similar.

Try v4.1-897-gb589a31 (without the testing patch). I believe that I fixed the wrong memory access.

Just a note: You may run tvh as root and use '-u tvh -g tvh' options to switch the process to another user when the resources are allocated. You may verify it using the ps cmd if the effective user is different than root for all threads. The fork is not required for this.

The fork issue is fixed in v4.1-898-g0c7f054 . Thank you for your investigation.

Could you try v4.1-900-gb9f2598 ?

that looks really good. scan completed sucessfully, and during first tests everything seems to work as expected. i will monitor this during the next days. Thank you very much.