Bug #3021
Panasonic SatIP Client on TVH SATIP server: No Signal
0%
Description
I just bought an ASX804 TV and wanted to connect it to TVH via satip. First I had lots of trouble to get the panasonic find any channels at all. I don't know what has changed, but for some reason searching channels worked suddenly. But now after I restarted TVH, I always get no signal when switching channels. I can see in the logs that something happens, so connection is established, but for some reason even if TVH says "RTP streaming to 192.168.178.47:3456 open" it seems like the TV does not receive data and will close the subscription again.
Attached the trace and a tcpdump of the data on port 554
Files
History
Updated by Volker V over 9 years ago
BTW with minisatip there was no problem at all. Neither with channel searching nor with signal receiving.
Updated by Jaroslav Kysela over 9 years ago
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).
Updated by Volker V over 9 years ago
- File ChannelSearch.zip ChannelSearch.zip added
I tried switching back to tvheadend but currently the problem is back that no channels are found at all, when using TVH as backend.
I added the tcpdump during the channel search for both backends. For me it seems that minisatip is responding with HTTP_STATUS_OK when a SETUP request is received, while TVH seems to not respond at all.
But I don't have a clue about RTSP or SatIP, so forgive me if I'm misinterpreting things.
Updated by Volker V over 9 years ago
Turned out, I had disabled the DVB input used by TVH, that was the reason there was no response from TVHEADEND with HTTP_STATUS_OK. After enabling it I can see traffic that is similar to minisatip, but still no channels on the TV.
Attached the new log for TVH.
Updated by Volker V over 9 years ago
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.
Updated by Volker V over 9 years ago
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.
Updated by Jaroslav Kysela over 9 years ago
Than it looks like an UPnP problem. It would be good to identify working / non-working packets on UDP port 1900 .
Updated by Volker V over 9 years ago
- File start_tvheadend_before_tv.txt start_tvheadend_before_tv.txt added
- File tv_already_on_tvh_start.txt tv_already_on_tvh_start.txt added
I added a dump in satips_upnp_discovery_received, satips_upnp_discovery_received (in case there is panasonic in the incoming string), in satips_upnp_send_discover_reply and in satips_upnp_send_announce
For me it looks quite similar in the case where I have the TV already on and start TVH afterwards and in the case where TVH has been started and I power on the TV after it.
The only difference is that in the case where the TV is already on, there seems to be a SETUP followed by a PLAY command send from the TV to TVH. While in the other case where TVH has been started before the TV, there is no such command comming in.
Could I trace something else, what may cause the TV to send a SETUP command to TVH?
Updated by Jaroslav Kysela over 9 years ago
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)...
Updated by Jaroslav Kysela over 9 years ago
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.
Updated by Volker V over 9 years ago
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
I saw in the TVH log output, that an announcement is send when TVH starts up, but never again later on. As the TV worked when it was powered on before TVH, I tried adding an announcement when replying to a discovery message. And lo and behold, it worked!
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); } }
I don't know it's that according to the specification, but at least it shouldn't be totally wrong and with that change, my TV finally works too.
Updated by Volker V over 9 years ago
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.
Updated by Volker V over 9 years ago
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"
Although the SATIP Server has a weight of 100, which I guess should be more important than weight 4 of the epggrabber.
Updated by Volker V over 9 years ago
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"
Updated by Volker V over 9 years ago
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!
Updated by Jaroslav Kysela over 9 years ago
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.
Updated by Wolfgang Ferl about 9 years ago
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 }
Updated by Volker V about 9 years ago
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
Updated by Jaroslav Kysela about 9 years ago
Volker, could you grab the initial network communication between TV and minisatip using tcpdump or wireshark ? Including multicasts ? Upload .pcap file here, please.
Updated by Volker V about 9 years ago
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.
Updated by Volker V about 9 years ago
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.
Updated by Wolfgang Ferl about 9 years ago
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.
Updated by Wolfgang Ferl about 9 years ago
- File minisatip_filtered.pcap minisatip_filtered.pcap added
I got minisatip up and running which seems to be working flawless out of box. Despite of that it would be really nice to get the same functionality from tvheadend.
as requested i tried to captured the traffic while starting the tv and tuning to a sat>ip channel. I've attached the filtered dmp (removed rtsp mpeg frames and anything elso from local netwerk). Im not absolutely sure if that contains the requested data. Hope i didn't remove something necessary. Otherwise tell me what eyxactly you are looking for, or i also could provide you a unfildered dump.
Updated by Jaroslav Kysela about 9 years ago
Wolfgang - thanks. Could you also do same for TVH answers (when it does not work) ? (gather pcap file)
Updated by Wolfgang Ferl about 9 years ago
- File tvheadend2_filtered.pcap tvheadend2_filtered.pcap added
- File tvheadend_filtered.pcap tvheadend_filtered.pcap added
as i didn't get it working anymore with tvheadend i will provide you the log from the attempt of a scan process. I tried it two times, and as i am unsure how to interpret the results i append both of them. Hope one of them contains some helpful informations. Thank you very much for looking into this issue.
Updated by Jaroslav Kysela about 9 years ago
Could you try v4.1-830-gaeb20ca ? (upload .pcap if it does not work, thanks)
Updated by Wolfgang Ferl about 9 years ago
attached the current log. from what i see in the tvheadend interface, tuning to the varying tranponders during channel scan seems to work, but on the tv neither the signal strengh is shown nor does the scan find any channels, except the channels from the initial tronsponder 10729 (The transponder that is preselected on tv when setting sattelite position Astra 19,2). Havent seen this behavior before, hope that leads you to the right direction. As the dump isn't that big this time i didn't remove the mpeg packets.
Updated by Jaroslav Kysela about 9 years ago
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' ?
Updated by Wolfgang Ferl about 9 years ago
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"
Updated by Jaroslav Kysela about 9 years ago
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.
Updated by Wolfgang Ferl about 9 years ago
- File tvheadend.log tvheadend.log added
crashes at first sat>ip tuning attempt, log file attached
Updated by Jaroslav Kysela about 9 years ago
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).
Updated by Wolfgang Ferl about 9 years ago
- File tvheadend.2015.11.04.log tvheadend.2015.11.04.log added
turned loggin on via webinterface, that may be the reason for the uncomplete log. Attached another log following your instruction.
Updated by Jaroslav Kysela about 9 years ago
Thanks. Could you apply the attached patch ? 'cat a.patch | patch -p1' in the git directory and retry ? The weight change might be ommited - just one tune test.
Updated by Wolfgang Ferl about 9 years ago
next attempt, thank you for your efforts.
Updated by Jaroslav Kysela about 9 years ago
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 .
Updated by Wolfgang Ferl about 9 years ago
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
Updated by Wolfgang Ferl about 9 years ago
- File logging.png logging.png added
could you tell me if the logging parameters are correct?
Updated by Jaroslav Kysela about 9 years ago
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
Updated by Jaroslav Kysela about 9 years ago
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).
Updated by Wolfgang Ferl about 9 years ago
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
Updated by Wolfgang Ferl about 9 years ago
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.
Updated by Wolfgang Ferl about 9 years ago
i really hope i didn't send you down a wrong track, but it seems it has something to do how i start the application. Now i ran the application in foreground, and scanning immediately worked. Anyhow it crashed in the middle of the scanning process. Not sure if this bug is the correct place, but i'll provide the log of this process. I repeated it two times, and it happen twice at the same position. Next thing is that i am again at the point where i don't know how i should start tvheadend with root permissions, so that port 554 can be used. And again, i have to apologize if i wasted your time because of a wrong setup in my field.
Updated by Jaroslav Kysela almost 9 years ago
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.
Updated by Jaroslav Kysela almost 9 years ago
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.
Updated by Jaroslav Kysela almost 9 years ago
The fork issue is fixed in v4.1-898-g0c7f054 . Thank you for your investigation.
Updated by Wolfgang Ferl almost 9 years ago
- File tvheadend.4.1.898.log tvheadend.4.1.898.log added
thank you very much. thats indeed a big step forward. Now the server is visible, and tuning to a existing channel is also possible. but i get a crash when perfomrming a channel scan. According to the log this happens repetitive on mux 11023H.
Updated by Wolfgang Ferl almost 9 years ago
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.