tvheadend: satip-client discovery not working(workaround) #16500

walterav1984 · 2021-08-30T21:37:16Z

Maintainer: @M95D
Environments tested:
bcm2708, Raspberry Pi 1, (OpenWrt version snapshot r17454-f08b76b32f, old-stable 19.07.8, stable 21.02.2,
OpenWrt SNAPSHOT r18801-56256259a1, OpenWrt SNAPSHOT r18807-7fae1e5677)
lantiq/xrx200, ZyXEL P-2812HNU-F1, (OpenWrt 21.02.2 r16495-bf0c965af0)

Devices routers/tuners and configs:
-RPi1 running OpenWrt ext4 image, only disabled DHCP server on LAN for this device:
*passive (static ip no DHCP server no default route using the LAN interface)
*active (LAN interface gets ip by DHCP-client not the WAN, and default route/dns from main router)

-ZyXEL P-2812HNU-F1(for testing besides the Raspberry Pi1, because it has more interfaces):
*default OpenWrt Lan/Wan Router config only changed WAN "dsl0" to "eth0.2"

-FritzBox 6490 Sat-IP tuner disabled DHCP server on LAN for this device:
*passive (static ip matching subnet of main router no default route)
*active(LAN interface gets DHCP from openwrt router or main router depending or setup)

-HDHomeRun:
*active(LAN gets DHCP ip-address from main router or OpenWrt Router Rpi1/Zyxel)

Issue Description:
Discovery of SAT>IP server based network tuners is not working out of the box with Tvheadend web-interface on OpenWrt.

You can let the satip-client function scan for satip-server based tuners by pressing the following button in the Tvheadend webinterface "Configuration>General>SATIP-Server>Discover SATIP-Servers". This would normally list (multiple) network satip and HDhomerun tuners in the "Configuration>DVB Inputs>TV Adapters" section.

Assuming that all devices are connected with each other via ethernet and configured for the same subnet as the OpenWrt "Lan" interface is using. Only the Raspberry or the Zyxel were tested in a setup as being the OpenWrt device not both together!
Both test cases of having a default OpenWrt router WAN/LAN config with a 192.168.1.1 subnet on its LAN with a DHCP server or a OpenWrt config not running as a router but as a passive/active LAN client were tested a long the way. All configuraties have this issue of not detecting SATIP tuners by default, except the config were the RPI1 has the one and only interface have its default route 0.0.0.0 and gateway set on its own LAN interface.

Fix:
Thanks to @M95D insight its possible to let "tvheadend" know on which interface the broadcast packets for detecting SATIP needs to go out. By default this is 0.0.0.0 but this mostly incorrect.

All configs and devices tested running 21.02.x / Snapshot benefit from the following solution to detect SATIP tuners, by specifying the "--bindaddr" option /etc/init.d/tvheadend, which is immune to changes of LAN ip-address/ranges after tvheadend has been installed:

start_service() {
	ensure_config_exists
	procd_open_instance
	procd_set_param file /etc/config/tvheadend
	chown -R root:$TVH_GROUP /dev/dvb/*
	LANIP=$(uci get network.lan.ipaddr) #<--- add this line
	#edit/complete the line below with the ---bindaddr $LANIP, snapshot release also shows user/group info
	procd_set_param command "$PROG" -B --bindaddr $LANIP
	load_uci_config
	procd_close_instance
}

Older Workaround/Fixes:
Depricated Permanent static Fix using the "bindaddr" option /etc/config/tvheadend for both stable 21.02.1 and SNAPSHOT:

uci set tvheadend.server.bindaddr=$(uci get network.lan.ipaddr)
uci commit

But satip-server based tuners cannot be detected unless the following shell command has been run on OpenWrt device before the discovery:ip route add 239.255.255.250/32 dev eth0. This has to be done every (re)boot, therefor requires a permanent prefered route/firewall rule?

Permanent older fix with 'uci' rule:

uci add network route
uci set network.@route[-1].interface='lan'
uci set network.@route[-1].type='multicast'
uci set network.@route[-1].target='239.255.255.250/32'
uci commit

#incase of a bridged lan interface... luci uci example adds the same 'lan' interface!

Workaround (old-stable 19.07.8):
A workaround for manually and staticly adding a satip-server based tuner if you know the device specific/unique xml url can be done by adding the following example at the end of line 83 of /etc/init.d/tvheadend, this is the only solution for old-stable 19.07.8 all the former solutions/workaronds don't work:

--satip_xml http://satipserveripfritzbox:49000/satipdesc.xml
--satip_xml http://satipserveripoctopusnet/octoserve/octonet.xml
--satip_xml http://genericsatipserverip:8080/description.xml
--satip_xml http://minisatipserverip:8080/desc.xml

#example as in line ~83 of /etc/init.d/tvheadend

	procd_set_param command "$PROG" -B --satip_xml http://192.168.1.178:49000/satipdesc.xml

#or multiple tuners

	procd_set_param command "$PROG" -B --satip_xml http://192.168.1.178:49000/satipdesc.xml --satip_xml http://192.168.1.179/octoserve/octonet.xml

Credit goes to Roland.A from the TvHeadend forum.

The text was updated successfully, but these errors were encountered:

M95D · 2021-08-31T08:56:08Z

Can't use "eth0" in a package. It's not the same interface for all routers.
I have no experience with multicast, so I can't suggest a solution, but I think it i saw some multicast options in Luci / Interfaces / Edit page.

walterav1984 · 2021-08-31T09:30:33Z

It is indeed a bit of grey area to look where the fix should come from Package or Distro side and maybe no fix at all.

Although tvheadend is running on the LAN interface/zone side OpenWrt, there is probably still some sort of blocking done on this multicast SSDP behaviour.

For now personally I could workaround it with some /etc/rc.local and delay/restart hacking of the service. Besides looking at Luci multicast options under interfaces I noticed the package "igmpproxy" and "netifyd" also mention this multicast range.

M95D · 2021-11-04T16:56:32Z

I noticed a new configuration for network devices was added in OpenWrt. Please try:
Network - Interfaces - Devices (tab) - "br-lan" - Configure - Check "Enable multicast support" - Save & Apply
There's also "Enable multicast querier" - I don't know what that is, but it may help.

walterav1984 · 2021-11-18T11:41:33Z

Thanks for bringing this up, was this change a 21.02 (.1) point release change or was this already the case in 21.02? Will post back if I have tested.

M95D · 2021-11-19T13:23:49Z

I don't know.
I think it was added to master branch since January '21. My previous working firmware, from January, had Devices tab, but settings popup didn't work. I noticed it after I updated to current master in October.
I don't know how and when changes are introduced to version branches.

BTW, I'm working on a new tvheadend package based on their master branch. I hope it will be ready next week. I would appreciate some testing.

M95D · 2021-12-08T10:22:57Z

New version ready to test.
380374b

M95D · 2021-12-30T11:59:32Z

Please close this issue if it's resolved.

walterav1984 · 2021-12-31T18:16:56Z

Haven't tested new version yet, but except from the multicast setting hint in Openwrt interfaces has anything related to satip/multicast detection been altered in the new tvheadend package?

M95D · 2022-01-01T17:07:34Z

No.

walterav1984 · 2022-02-14T11:04:32Z

I noticed a new configuration for network devices was added in OpenWrt. Please try:
Network - Interfaces - Devices (tab) - "br-lan" - Configure - Check "Enable multicast support" - Save & Apply
There's also "Enable multicast querier" - I don't know what that is, but it may help.

This checkbox is currently activated by default in snapshot but doesn't help detecting satip tuners!

I don't know. I think it was added to master branch since January '21. My previous working firmware, from January, had Devices tab, but settings popup didn't work. I noticed it after I updated to current master in October. I don't know how and when changes are introduced to version branches.

Also noticed this strange popup about applying changes to network interface in that section of luci ,although nothing was altered or changed only upgraded to a stable point release of OpenWrt...

In current snapshot TvHeadend still doesn't detect SATIP tuners out of the box nor after pressing detect button "Configuration>General>SATIP-Server>Discover SATIP-Servers" neither on lan or br-lan interface, although HDHomeRun tuners are listed instantly without a hitch:
OpenWrt SNAPSHOT r18801-56256259a1 / LuCI Master git-22.025.79016-22e2bfb
HTS Tvheadend 2efe90cdcf74fdc4179692d283cf46c85e1cf681~openwrt5

Using the previous workaround but this time in 'uci' syntax (generated by luci webinterface) instantly detects the SATIP tuners after pressing detect and survives reboots:

uci add network route
uci set network.@route[-1].interface='lan'
uci set network.@route[-1].type='multicast'
uci set network.@route[-1].target='239.255.255.250/32'
uci commit

Maybe an idea to apply this 'uci' rule by default on the 'lan' interface when installing Tvheadend package?

M95D · 2022-02-16T07:22:54Z

As I said, I don't have any SAT>IP available to test, but adding a route may upset other packages that use multicast, maybe even tvheadend's iptv.
Can you try to see if binding tvheadend to local IP works?
Edit /etc/config/tvheadend, set option bindaddr to router's LAN IP and restart tvheadend.

Also try this:

Open the router's console (ssh or serial).
Stop tvheadend server:
/etc/init.d/tvheadend stop
Run the server with this command:
tvheadend -c /etc/tvheadend -u tvheadend -g dvb -B --satip_bindaddr <router's LAN IP>
(I assume you have the latest snapshot installed, the one that doesn't run as root. If not, remove the user and group switches.)

walterav1984 · 2022-02-16T20:20:10Z

Dear @M95D this "option bindaddr" in /etc/config/tvheadend with the lan-address is indeed the solution and works both for the the current snapshot but also the current stable OpenWrt 21.02.1 which is now also able to detect and use both HDHomeRun and SAT-IP tuners.

Now its not even required to add the "multicast route" discussed earlier, which had no effect at all on 21.02.1.

Starting up the server manually both in 21.02.1 as root and SNAPSHOT tvheadend/dvb using the following commands did not work because "satip_bindaddr" is not a valid option:

tvheadend -c /etc/tvheadend -B --satip_bindaddr <router's LAN IP>
tvheadend -c /etc/tvheadend -u tvheadend -g dvb -B --satip_bindaddr <router's LAN IP>

However starting up the server manually both in 21.02.1 as root and SNAPSHOT tvheadend/dvb using the following commands did work the same as editing /etc/config/tvheadend offcourse the #option bindaddr were commented to check this command:

tvheadend -c /etc/tvheadend -B --bindaddr <router's LAN IP>
tvheadend -c /etc/tvheadend -u tvheadend -g dvb -B --bindaddr <router's LAN IP>

By proposing a general solution is it possible to add the following command as a post install action of the tvheadend 21.02.1/snapshot package to make the "bindaddr" option by default attach to the lan interface instead of 0.0.0.0 which doesn't work?

uci set tvheadend.server.bindaddr=$(uci get network.lan.ipaddr)
uci commit

M95D · 2022-02-16T21:08:23Z

Glad to see that --bindaddr works. I already asked in OpenWrt forum and Jow's answer explained a lot. I'll try to make a script that sets bindaddr to LAN IP, following Jow's advice, but it's complicated and I never done this before. It will take a while.

M95D · 2022-02-16T21:08:59Z

https://forum.openwrt.org/t/bind-service-to-local-ip/120436

walterav1984 · 2022-02-16T21:27:22Z

Indeed the comprehensive solution is to make it flexable to changes of the lan ipaddress or device even when these gets altered after tvheadend has been installed. I can only confirm that uci get network.lan.ipaddr works for both br-lan or lan.

walterav1984 · 2022-02-16T21:51:43Z

Permanent dynamic Fix (21.02.x/Snapshots) by only adding the --bindaddr option in /etc/init.d/tvheadend and neglecting /etc/config/tvheadend, this makes it immune to changes of lan ip-address/ranges after tvheadend has been installed:

...
start_service() {
	...
	LANIP=$(uci get network.lan.ipaddr) #add this to detect the right ip/interface
	procd_set_param command "$PROG" -B --bindaddr $LANIP #<--- see addition of --bindaddr #snapshot also needs -u $TVH_USER -g $TVH_GROUP 
	...
}
...

walterav1984 · 2022-02-18T12:40:22Z

Another interesting fact... 🤦 🤦 🤦

I did most of the testing on a offline/passive connected RPi1 with its only ethernet interface being temporary used as a "wan" client to the internet for doing the opkg update;opkg install tvheadend than reverting to a single port "lan" config with only dhcp server ignore 1 on a static ip matching and bridged with my current LAN setup containing router/SAT-IP/HDHomeRun-tuners/AP's/Servers/etc. The meaning of all this, there was no default 0.0.0.0 route at all on the RPi1(no ntp/clock/opkg/etc), only traffic in the same subnet possible! This while tvheadend throws its discovery broadcast by default for SATIP on that 0.0.0.0 interface, which was absent...

But when adding the default gateway and route on the 'LAN' interface, tvheadend instantly detects the
the SATIP tuners, without former "multicast route", "bindaddr" or "satip_xml" options or other workarounds! But offcourse the setup is very simple without any other physical/virtual ethernet interfaces tvheadend may mistake!
👏 👏 👏

However I will try a more default router setup soon (wan+(w)lan+switch+HDHomeRun/SATIP tuners within LAN) but my guess is that the SATIP broadcasts will be passed upstream on the WAN if using the 0.0.0.0 preset of tvheadend and it will still not always work since its a hit/or miss according to this topic with multiple interfaces.

Therefor I still think the solution posted in the former post above ^^^ is the way to go for 21.02.2/Snapshot. Sadly this default route insight had no effect on 19.07.8...

walterav1984 · 2022-02-18T19:18:04Z

Zyxel OpenWrt router tested with a complete default config first post edited with details but the result remains still the same... Tvheadend won't detect SATIP tuners without the --bindaddr fix.

M95D · 2022-02-19T09:24:47Z

Yes, you are correct. It probably sends multicasts on the interface that has the default route (route to 0.0.0.0). It might not even be an issue specific to tvheadend. Probably all linux multicasts go out on the the interface having the default route, unless the app binds some another interface. And routers usually have 0.0.0.0 go out on the wan interface (because that's where the internet is).
I wrote the patch. Test the snapshot again after the patch is merged. Or, if you don't want to wait, just patch the startup script yourself. It's just one extra line.

walterav1984 · 2022-02-19T10:04:53Z

Thanks, I will test and close this ticket as soon it as been merged master and backported to stable 21.02.x.

walterav1984 · 2022-02-19T12:16:11Z

Tested successful both on RaspberryPi1(LAN-ip client active/passive) and Zyxel P-2812HNU-F1(normal router WAN/LAN config) running OpenWrt 21.02.2 with Tvheadend package are able to instantly detect SATIP-tuner (fritzbox 6490 v07.29, with static ip-address matching the LAN interface subnet of the OpenWrt devices) with this patched manually.

walterav1984 · 2022-02-19T12:27:51Z

Since this fix for master is merged and 21.02.x branch needs backporting, should we still care about 19.07.x and add a --satip_xml option to /etc/config/tvheadend this is easier for users than editing /etc/init.d/tvheadend and won't interfere with your patch? The "bindaddr" option is not working at all in that 4.0.x Tvheadend release, also the other multicast route workarounds...

I already succesful tested having this option active in 19.07.8 by adding the following code to /etc/init.d/tvheadend:

        config_get satip_xml server satip_xml
	[ -n "$satip_xml" ] && procd_append_param command --satip_xml "$satip_xml"

Than adding a single specific/unique SATIP tuner of choice to /etc/config/tvheadend:

config tvheadend server
	option ipv6 '1'
	# If bindaddr is not set, it will default to LAN IP address (uci get network.lan.ipaddr).
	# To bind all interfaces, set it to "0.0.0.0".
#	 option bindaddr '0.0.0.0'
#	 option satip_xml 'http://satipserveripfritzbox:49000/satipdesc.xml'
#	 option satip_xml 'http://satipserveripoctopusnet/octoserve/octonet.xml'
#	 option satip_xml 'http://genericsatipserverip:8080/description.xml' #only the last will work <-----
#	 option http_port '9981'
#	 option http_root '/tvheadend'

The only downside is that it will only work for 1 tuner, adding multiple satip_xml listings makes only the last work contrary to adding multiple --satip_xml additions after each other directly in /etc/init.d/tvheadend which does work for multiple tuners...

#example as in line ~83 of /etc/init.d/tvheadend

	procd_set_param command "$PROG" -B --satip_xml http://192.168.1.178:49000/satipdesc.xml --satip_xml http://192.168.1.179/octoserve/octonet.xml

M95D · 2022-02-19T15:45:30Z

It would be better to update tvheadend version.

If config parameter is not set, tvheadend will bind to LAN IP address by default. Fixes issue #16500 without requiring user modifications to config file. It's also more secure if firewall becomes disabled. Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro>

walterav1984 · 2022-03-09T10:12:31Z

This current merged fix has been tested and verified working both under "OpenWrt SNAPSHOT r19075-ed364cd4b0" as of today master branch and "manually patched" 21.02.2 branch using a Raspberry Pi1 as OpenWrt router and Fritzbox 6490 as Satip server&tuner.

It however still needs backporting to 21.02.x branch with simply a cherrypick and no further changes needed.
95cbfe8

Is it up to the maintainer @M95D or commiter @neheb to backport?

neheb · 2022-03-09T10:14:14Z

Typically the former.

walterav1984 · 2022-03-14T21:24:41Z

Closing this since master and stable are just patched and old-stable 19.07.x will be EOL soon.

If config parameter is not set, tvheadend will bind to LAN IP address by default. Fixes issue openwrt#16500 without requiring user modifications to config file. It's also more secure if firewall becomes disabled. Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro>

If config parameter is not set, tvheadend will bind to LAN IP address by default. Fixes issue openwrt#16500 without requiring user modifications to config file. It's also more secure if firewall becomes disabled. Signed-off-by: Marius Dinu <m95d+git@psihoexpert.ro> (cherry picked from commit 95cbfe8)

walterav1984 mentioned this issue Aug 30, 2021

tvheadend: Please add hdhomerun support #3342

Closed

M95D mentioned this issue Feb 18, 2022

tvheadend: bind to LAN IP by default #17896

Merged

M95D mentioned this issue Mar 9, 2022

tvheadend: bind to LAN IP by default #18037

Merged

walterav1984 closed this as completed Mar 14, 2022

walterav1984 mentioned this issue Mar 26, 2022

DM500 Satip not found by Tvheadend mildsunrise/dm500-satip#11

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tvheadend: satip-client discovery not working(workaround) #16500

tvheadend: satip-client discovery not working(workaround) #16500

walterav1984 commented Aug 30, 2021 •

edited

Loading

M95D commented Aug 31, 2021

walterav1984 commented Aug 31, 2021

M95D commented Nov 4, 2021

walterav1984 commented Nov 18, 2021

M95D commented Nov 19, 2021 •

edited

Loading

M95D commented Dec 8, 2021 •

edited

Loading

M95D commented Dec 30, 2021

walterav1984 commented Dec 31, 2021

M95D commented Jan 1, 2022

walterav1984 commented Feb 14, 2022 •

edited

Loading

M95D commented Feb 16, 2022 •

edited

Loading

walterav1984 commented Feb 16, 2022 •

edited

Loading

M95D commented Feb 16, 2022

M95D commented Feb 16, 2022

walterav1984 commented Feb 16, 2022

walterav1984 commented Feb 16, 2022 •

edited

Loading

walterav1984 commented Feb 18, 2022

walterav1984 commented Feb 18, 2022

M95D commented Feb 19, 2022

walterav1984 commented Feb 19, 2022

walterav1984 commented Feb 19, 2022 •

edited

Loading

walterav1984 commented Feb 19, 2022 •

edited

Loading

M95D commented Feb 19, 2022

walterav1984 commented Mar 9, 2022

neheb commented Mar 9, 2022

walterav1984 commented Mar 14, 2022

tvheadend: satip-client discovery not working(workaround) #16500

tvheadend: satip-client discovery not working(workaround) #16500

Comments

walterav1984 commented Aug 30, 2021 • edited Loading

M95D commented Aug 31, 2021

walterav1984 commented Aug 31, 2021

M95D commented Nov 4, 2021

walterav1984 commented Nov 18, 2021

M95D commented Nov 19, 2021 • edited Loading

M95D commented Dec 8, 2021 • edited Loading

M95D commented Dec 30, 2021

walterav1984 commented Dec 31, 2021

M95D commented Jan 1, 2022

walterav1984 commented Feb 14, 2022 • edited Loading

M95D commented Feb 16, 2022 • edited Loading

walterav1984 commented Feb 16, 2022 • edited Loading

M95D commented Feb 16, 2022

M95D commented Feb 16, 2022

walterav1984 commented Feb 16, 2022

walterav1984 commented Feb 16, 2022 • edited Loading

walterav1984 commented Feb 18, 2022

walterav1984 commented Feb 18, 2022

M95D commented Feb 19, 2022

walterav1984 commented Feb 19, 2022

walterav1984 commented Feb 19, 2022 • edited Loading

walterav1984 commented Feb 19, 2022 • edited Loading

M95D commented Feb 19, 2022

walterav1984 commented Mar 9, 2022

neheb commented Mar 9, 2022

walterav1984 commented Mar 14, 2022

walterav1984 commented Aug 30, 2021 •

edited

Loading

M95D commented Nov 19, 2021 •

edited

Loading

M95D commented Dec 8, 2021 •

edited

Loading

walterav1984 commented Feb 14, 2022 •

edited

Loading

M95D commented Feb 16, 2022 •

edited

Loading

walterav1984 commented Feb 16, 2022 •

edited

Loading

walterav1984 commented Feb 16, 2022 •

edited

Loading

walterav1984 commented Feb 19, 2022 •

edited

Loading

walterav1984 commented Feb 19, 2022 •

edited

Loading